DETAILED CORRESPONDANCE
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of claims
This final office action on merits is in response to the communication received on 04/29/2026. Claim 10 is cancelled. Amendments to claims 1, 11, 18, and 21 are acknowledged and have been carefully considered. Claims 1-9, and 11-21 are pending and considered below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-9, and 11-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1-9, and 21 are drawn to an intelligent classification (IC) computing system, claims 11-17 are drawn to a non-transitory computer-readable storage medium, and claims 18-20 are drawn to a method. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 1 recites the limitations of configuring the admission data into input data for a machine learning (ML) model configured to automatically classify the data by admission type; analyzing the input data to determine additional admission data associated with the admission of the at least one patient that is not included in the message based upon the training of the ML model to request additional data; determining a second medical service provider to request the additional admission data from, the second medical service provider being different from the first medical service provider; generating a classification output based upon the admission data and the additional admission data, the classification output comprising a predicted classification for the admission defining a reason for the admission; based upon the classification output, automatically classifying the admission as an admission type, of a plurality of admission types, associated with the at least one patient. These limitations, as drafted, are processes that, under their broadest reasonable interpretations, encompass observation, evaluation, and judgement that can practically be performed in the mind or by using a pen and paper. For example, a person could review available admission information, determine whether additional information is needed, identify an appropriate source from which to obtain the additional information, evaluate the combined information to predict a reason for the admission, and classify the admission in to an admission type. Even when considering the “at least one processor in communication with at least one database” or “the ML model” language, the claim recites generic computer components as tools to perform these evaluations and judgements rather than reciting an improvement to computer technology itself. The mere nominal recitation of at least one processor in communication with at least one database or the ML model does not take the claim limitation out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
Independent claims 11 and 18 recite identical or nearly identical steps with respect to claim 1 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per claim 1, include:
at least one processor in communication with at least one database, the at least one processor configured to:
receive a message including admission data associated with an admission of at least one patient with a first medical service provider;
configure the admission data into input data for a machine learning (ML) model configured to automatically classify the data by admission type;
input the input data into the ML model, wherein the ML model is a gradient boosted decision tree model that is trained to request additional data associated with admissions in order to accurately classify the admissions based upon i) historical admission data provided during historical admissions and ii) historical additional data retrieved to supplement the historical admission data in classifying the historical admissions, wherein based upon receipt of the admission data, the ML model is configured to:
analyze the input data to determine additional admission data associated with the admission of the at least one patient that is not included in the message based upon the training of the ML model to request additional data;
determine a second medical service provider to request the additional admission data from, the second medical service provider being different from the first medical service provider;
request and receive, from a first external computing device associated with the second medical service provider, the additional admission data; and
generate a classification output based upon the admission data and the additional admission data, the classification output comprising a predicted classification for the admission defining a reason for the admission;
based upon the classification output, automatically classify the admission as an admission type, of a plurality of admission types, associated with the at least one patient;
based upon automatically classifying the admission, generate a patient data file and an authorization message associated with the admission of the at least one patient;
store the patient data file in the at least one database; and
transmit the authorization message to a second external computing device for approval.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of evaluating admission information to determine additional information, predict a reason for a patient’s admission, and classify the admission into an admission type in a computer environment. The claimed computer components (i.e., at least one processor in communication with at least one database, the at least one processor configured to; wherein the ML model is a gradient boosted decision tree model that is trained to request additional data associated with admissions in order to accurately classify the admissions based upon i) historical admission data provided during historical admissions and ii) historical additional data retrieved to supplement the historical admission data in classifying the historical admissions, wherein based upon receipt of the admission data, the ML model is configured to; and from a first external computing device associated with the second medical service provider) are recited at a high level of generality and are merely invoked as tools to perform an existing process of collecting, analyzing, and classifying admission information. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim recites the additional elements of receiving a message including admission data associated with an admission of at least one patient with a first medical service provider; inputting the input data into the ML model; requesting and receiving the additional admission data; based upon automatically classifying the admission, generating a patient data file and an authorization message associated with the admission of the at least one patient; storing the patient data file in the at least one database; and transmitting the authorization message to a second external computing device for approval. These limitations are recited at a high level of generality (i.e., as a general means of collecting information for analysis and communicating or recording the results of the analysis), and amounts to mere data gathering and insignificant application, which are forms of insignificant extra-solution activities. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of evaluating admission information to determine additional information, predict a reason for a patient’s admission, and classify the admission into an admission type in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
For claim 1, under step 2B, the additional elements of receiving a message including admission data associated with an admission of at least one patient with a first medical service provider; inputting the input data into the ML model; requesting and receiving the additional admission data; based upon automatically classifying the admission, generating a patient data file and an authorization message associated with the admission of the at least one patient; storing the patient data file in the at least one database; and transmitting the authorization message to a second external computing device for approval have been evaluated. The intelligent classification computing system comprising at least one processor in communication with at least one database performs a general function of receiving patient data for receiving, storing, and transmitting patient data for analysis and classification which represents a well-understood, routine, and conventional activity in the field of computer implemented data processing and healthcare information management. The specification discloses that the processor is used in its ordinary capacity as a data input device and does not describe any improvement to the computer itself or to the functioning of the overall computer system (see [0078]-[0079]). Also noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for analysis without a technological improvement does not add significantly more to an abstract idea. The use of the intelligent classification computing system is no more than collecting information before performing analysis and classification of the admission information and does not integrate the abstract idea into a practical application. Additionally, as noted in In re Brown, 645 Fed. App'x 1014, 1016-1017 (Fed. Cir. 2016), merely generating records or messages based on the analysis, storing those records, and communicating the results to another computing device represents an insignificant application of the underlying mental process, as the generation, storage, and transmission merely record and communicate the results of the analysis for subsequent use or approval and does not impose any meaningful limitation or add any technological improvement. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 2-3, 12-13, 19-20 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claims 4-9, 14-17, and 21 recite the additional element of the ML model (claims 4-8 and 14-17), and at least one processor (claims 9 and 21); receive the historical admission data associated with the historical admissions (claim 21), receive the at least one portion of historical data (claim 21), transmit a request for the at least one portion of historical data to the computing device (claim 21), and train the ML model based upon the historical admission data and the at least one portion of historical data, the at least one portion of historical data included in the historical additional data (claim 21). However, these additional element amount to implementing an abstract idea on a generic computing device, mere data gathering or insignificant application (i.e., insignificant extra-solution activities). As such, these additional elements, when considered individually or in combination with the prior devices, do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claims are rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, 6-9, 11-12, 14, 16-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas et al. (U.S. Patent Publication 2021/0098090 A1), referred to hereinafter as Thomas, in view of Rapaka et al. (U.S. Patent Publication 2018/0315182 A1) referred to hereinafter as Rapaka, and Rao et al. (U.S. Patent Publication 2020/0321086 A1) referred to hereinafter as Rao.
Regarding claim 1, Thomas teaches an intelligent classification (IC) computing system comprising at least one processor in communication with at least one database, the at least one processor configured to (Thomas [0085] “In some implementations of these embodiments, the complex patient identification component 402 can employ one or more machine learning techniques to learn correlations between the various discharge care outcomes (e.g., discharge destinations and associated probabilities, LOS, readmission risk, safety risks, etc.), clinical factors, and non-clinical factors described herein and patients historically considered complex needs patients to facilitate determining whether a currently admitted patient should be classified as a complex needs patient. For example, the complex patient identification component 402 can learn correlations between discharge destinations, LOS, readmission risk, and/or safety risks, to a patient being classified as complex needs. In another example, the complex patient identification component 402 can learn what specific combinations of the clinical and non-clinical parameters (and the parameter values) included in the input data 104 correlate to a patient considered to be complex needs. The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”,
Thomas [0132] “One or more embodiments can be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”, and
Thomas [0006] “In some implementations, the non-clinical data points comprise information regarding post-discharge patient support, including individuals responsible for caring for the respective patients after their discharge from the hospital, such as friends, family members, home care assistants, and the like. The non-clinical data points can also comprise information regarding patient socioeconomic status (e.g., income level, standard of living, tax bracket, profession, etc.). The non-clinical data points can also comprise patient demographic information (e.g., age, gender, ethnicity, home location, religion, marital status, etc.), and patient insurance information. The clinical data points can include both historical medical information about a patient received from one or more existing databases (e.g., electronic health record (EHR) databases) as well as clinical data collected for a patient from various data sources in real-time over the course of their inpatient stay.”):
receive a message including admission data associated with an admission of at least one patient with a first medical service provider (Thomas [0033] “The disclosed techniques for predicting patient care outcomes employ one or more machine learning models respectively trained to predict the patient care outcome based on learned correlations between a variety of unique combinations of clinical and non-clinical factors. For example, the clinical factors can include information regarding the patient's medical history prior to admission, as well as admission data regarding the reason for admission, patient status and diagnosis upon admission, initial clinical orders for the patient, an initial care plan for the patient, and the like. The clinical data can also include tracked clinical information collected for the patient over their inpatient stay, including information regarding medical procedures performed and scheduled, clinicians involved in the patient's care (e.g., physicians, nurses, technicians, etc.), laboratory tests conducted, imaging studies performed, medications administered, and the like. The tracked clinical information can also include information regarding monitored vital signs (e.g., captured and reported in real-time), monitored patient status (e.g., including changes in patient's status over time), tracked patient location, and the like.”);
configure the admission data into input data for a machine learning (ML) model configured to automatically classify the data by admission type (Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”, and
Thomas [0083] “In this regard, in some implementations, the complex patient identification component 402 can determine whether a currently admitted patient is a complex needs patient (or not) based on their forecasted discharge destination(s) and placement probability. For example, certain defined discharge destinations can be associated with complex needs patients. In one implementation of this embodiment, the complex needs patient identification component 402 can classify all patients that receive a predicted discharge destination to one that is associated with complex needs patients, as complex needs patients. For example, the complex patient identification component 402 can classify all patients that receive a forecasted discharge destination to a LTAC disposition as complex needs patients based on previously defined information associating the LTAC disposition with complex needs patients. In another implementation, the complex patient identification component 402 can also determine whether a patient is a complex needs patient based on whether the predicted probability of the patient being discharged to a disposition included in the complex needs group is above a defined probability threshold. For example, the complex patient identification component 402 can classify all patients that receive a forecasted discharge destination to a LTAC disposition with a probability of 70% or higher as complex needs patients based on previously defined information associating the LTAC.” );
input the input data into the ML model, wherein the ML model is a gradient boosted decision tree model; in order to accurately classify the admissions based upon i) historical admission data provided during historical admissions, wherein based upon receipt of the admission data, the ML model is configured to (Thomas [0051] “Thus, in various embodiments, the one or more discharge destination forecasting models 126 can include previously trained/developed models. For example, the one or more discharge destination forecasting models 126 can include one or more models trained on training data including same or similar clinical and non-clinical features included in the input data 104 and recorded discharge information (e.g., discharge document files) identifying actual discharge dispositions where the patients represented in the training data were discharged. It should be appreciated that the model training process can vary based on the type machine learning algorithms employed by the respective discharge destination forecasting models 126, which can vary. For example, some suitable machine learning algorithms/models that can be used for the one or more discharge destination forecasting models 126 can include but are not limited to: a nearest neighbor algorithm, a naïve Bayes algorithm, a decision tree algorithm, a boosting algorithm, a gradient boosting algorithm, a linear regression algorithm, a neural network algorithm, a k-means clustering algorithm, an association rules algorithm, a q-learning algorithm, a temporal difference algorithm, a deep adversarial network algorithm, or a combination thereof. As described in greater detail infra with reference to FIGS. 6-8, in some embodiments, the one or more discharge forecasting models 126 can include a plurality of different models respectively configured to process different types of input parameters, employ different machine learning algorithms, and/or provide different biases toward certain patient groups. In some embodiments, (discussed in greater detail infra with reference to FIG. 13), the one or more discharge destination forecasting models 126 can also be regularly updated/optimized over time based on the input data 104 and discharge information indicating the actual destinations where the patients were actually discharged, as well as user feedback regarding identified discharge barriers for certain patients (e.g., using one or more supervised and/or unsupervised machine learning mechanisms).”), and
Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”);
analyze the input data and based upon the training of the ML model (Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”, and
Thomas [0051] “Thus, in various embodiments, the one or more discharge destination forecasting models 126 can include previously trained/developed models. For example, the one or more discharge destination forecasting models 126 can include one or more models trained on training data including same or similar clinical and non-clinical features included in the input data 104 and recorded discharge information (e.g., discharge document files) identifying actual discharge dispositions where the patients represented in the training data were discharged. It should be appreciated that the model training process can vary based on the type machine learning algorithms employed by the respective discharge destination forecasting models 126, which can vary. For example, some suitable machine learning algorithms/models that can be used for the one or more discharge destination forecasting models 126 can include but are not limited to: a nearest neighbor algorithm, a naïve Bayes algorithm, a decision tree algorithm, a boosting algorithm, a gradient boosting algorithm, a linear regression algorithm, a neural network algorithm, a k-means clustering algorithm, an association rules algorithm, a q-learning algorithm, a temporal difference algorithm, a deep adversarial network algorithm, or a combination thereof. As described in greater detail infra with reference to FIGS. 6-8, in some embodiments, the one or more discharge forecasting models 126 can include a plurality of different models respectively configured to process different types of input parameters, employ different machine learning algorithms, and/or provide different biases toward certain patient groups. In some embodiments, (discussed in greater detail infra with reference to FIG. 13), the one or more discharge destination forecasting models 126 can also be regularly updated/optimized over time based on the input data 104 and discharge information indicating the actual destinations where the patients were actually discharged, as well as user feedback regarding identified discharge barriers for certain patients (e.g., using one or more supervised and/or unsupervised machine learning mechanisms).”);
receive the additional admission data (Thomas [0110] “In some embodiments, the optimization component 602 can receive additional input data 910 including user feedback data 912 and/or system state data 914 to facilitate determining optimized discharge destination forecasts and/or optimized discharge time forecasts. The user feedback data 912 can include information relevant to a patient's discharge provided by one or more individuals involved in the patient's care (e.g., a care provider, a case worker, a family member, a friend, the patient, etc.). For example, the user feedback data 912 can include user reported information identifying barriers to discharge including clinical and non-clinical tasks to be performed and/or scheduled prior to discharge, during discharged and/or following discharge (e.g., arranging dialysis, scheduling a consult, arranging/scheduling transportation, managing dietary requirements, setting up medication delivery, etc.). The user feedback data 912 can also include information regarding completed tasks and/or discharge milestones. The user feedback data 912 can include contextual information regarding arranging and performing check out of the patient from the hospital, including information regarding who will be accompanying the patient away from the hospital, when they will be arriving, how they will be transporting the patient, and the like.”);
generate a classification output based upon the admission data and the additional admission data, the classification output comprising a predicted classification for the admission defining a reason for the admission (Thomas [0085] “In some implementations of these embodiments, the complex patient identification component 402 can employ one or more machine learning techniques to learn correlations between the various discharge care outcomes (e.g., discharge destinations and associated probabilities, LOS, readmission risk, safety risks, etc.), clinical factors, and non-clinical factors described herein and patients historically considered complex needs patients to facilitate determining whether a currently admitted patient should be classified as a complex needs patient. For example, the complex patient identification component 402 can learn correlations between discharge destinations, LOS, readmission risk, and/or safety risks, to a patient being classified as complex needs. In another example, the complex patient identification component 402 can learn what specific combinations of the clinical and non-clinical parameters (and the parameter values) included in the input data 104 correlate to a patient considered to be complex needs. The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”, and
Thomas [0033] “The disclosed techniques for predicting patient care outcomes employ one or more machine learning models respectively trained to predict the patient care outcome based on learned correlations between a variety of unique combinations of clinical and non-clinical factors. For example, the clinical factors can include information regarding the patient's medical history prior to admission, as well as admission data regarding the reason for admission, patient status and diagnosis upon admission, initial clinical orders for the patient, an initial care plan for the patient, and the like. The clinical data can also include tracked clinical information collected for the patient over their inpatient stay, including information regarding medical procedures performed and scheduled, clinicians involved in the patient's care (e.g., physicians, nurses, technicians, etc.), laboratory tests conducted, imaging studies performed, medications administered, and the like. The tracked clinical information can also include information regarding monitored vital signs (e.g., captured and reported in real-time), monitored patient status (e.g., including changes in patient's status over time), tracked patient location, and the like.”);
based upon the classification output, automatically classify the admission as an admission type, of a plurality of admission types, associated with the at least one patient (Thomas [0085] “In some implementations of these embodiments, the complex patient identification component 402 can employ one or more machine learning techniques to learn correlations between the various discharge care outcomes (e.g., discharge destinations and associated probabilities, LOS, readmission risk, safety risks, etc.), clinical factors, and non-clinical factors described herein and patients historically considered complex needs patients to facilitate determining whether a currently admitted patient should be classified as a complex needs patient. For example, the complex patient identification component 402 can learn correlations between discharge destinations, LOS, readmission risk, and/or safety risks, to a patient being classified as complex needs. In another example, the complex patient identification component 402 can learn what specific combinations of the clinical and non-clinical parameters (and the parameter values) included in the input data 104 correlate to a patient considered to be complex needs. The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”);
based upon automatically classifying the admission, generate a patient data file and an authorization message associated with the admission of the at least one patient (Thomas [0129] “At 1502, a system operatively coupled to a processor (e.g., system 100, system 400, system 600, system 900, system 1200 or the like), employs one or more discharge forecasting machine learning models (e.g., discharge forecasting models 126) to predict discharge destinations where respective patients that are currently admitted to a hospital will be placed after discharge from the hospital (e.g., using discharge destination forecasting component 128), wherein the one or more discharge forecasting machine learning models predict the discharge destinations based on clinical data points (e.g., clinical patient data 106) and non-clinical data points (e.g., non-clinical patient data 108) collected for the respective patients. At 1504, the system employs one or more LOS forecasting machine learning models (e.g., LOS forecasting model 122) to predict discharge times when the respective patients will be discharged from the hospital based on the clinical data points and the non-clinical data points (e.g., using LOS forecasting component 134). At 1506, the system provides discharge information identifying the discharge destinations predicted for the respective patients to one or more care providers to facilitate managing and coordinating inpatient and post-discharge care for the respective patients (e.g., via reporting component 116).”,
Thomas [0117] “With reference again to FIG. 9, the system state data 914 can include dynamic, real-time information regarding variable conditions associated with the state of the inpatient facility (e.g., hospital) where patients are being discharged from, as well as the state of the discharge destinations where patients are being discharged too, that can influence when and where the patients are discharged. For example, the system state data 914 can include real-time information regarding the operating conditions/contexts of the hospital that vary and can influence when and where a patient is discharged, including information regarding patient flow, bed availability, wait times for beds, and availability of resources (e.g., availability of care providers to assist patients, availability of medical supplies/equipment, availability of transportation services, etc.) and the like. The system state data 914 can also include information regarding the operating conditions/contexts of the respective discharge facilities where patients may be discharged, including information regarding bed availability and demand (e.g., wait times), availability of resources at the respective discharge facilities (e.g., patient needs “xyz” resources at the discharge facility upon arrival but these aren't available, aren't working, have long wait times, etc.) and the like. The system state data 914 can also include real-time information regarding insurance authorization processing, including whether an authorization request is pending, expected time to approval, and the like.”, and
Thomas [0118] “In this regard, in some embodiments, the optimization component 602 can further facilitate determining optimized discharge destinations forecasts, recommending preferred discharged destinations (e.g., when more than one discharge destination can provide the level and type of care a patient requires) and/or determining optimized discharge time forecasts based on the user feedback data 912 and/or the system state data 914. For example, the optimization component 602 can employ information regarding barriers to discharge reported in the user feedback data 912 to identify and select one or more discharge dispositions that account for the barriers (e.g., discharge dispositions that are possible in view of the barriers and/or that minimize or eliminate barriers), and/or to adjust the placement probabilities associated with one or more possible discharge dispositions based on the barriers. The optimization component 602 can also employ information regarding bed availability, wait times, availability of resources, discharge check out arrangements, insurance authorization processing and the like, included in received system state data 914 to identify and select one or more discharge dispositions that account for the factors and/or to adjust the placement probabilities associated with one or more possible discharge dispositions based on the barriers. For example, even once a patient is ready for discharge, it could take days for an insurance provider to review a patient's medical record to authorize discharged to a post-acute care facility. By the time the process is finished, a bed may not be available in the facility of the patient's choice the discharge. In accordance with this example, the optimization component 602 can employ real-time information included in the system state data 914 regarding bed availability at discharge destination options and expected time to receiving insurance authorization for placement to better predict where a patient will be discharged.”);
the authorization message for approval (Thomas [0118] “In this regard, in some embodiments, the optimization component 602 can further facilitate determining optimized discharge destinations forecasts, recommending preferred discharged destinations (e.g., when more than one discharge destination can provide the level and type of care a patient requires) and/or determining optimized discharge time forecasts based on the user feedback data 912 and/or the system state data 914. For example, the optimization component 602 can employ information regarding barriers to discharge reported in the user feedback data 912 to identify and select one or more discharge dispositions that account for the barriers (e.g., discharge dispositions that are possible in view of the barriers and/or that minimize or eliminate barriers), and/or to adjust the placement probabilities associated with one or more possible discharge dispositions based on the barriers. The optimization component 602 can also employ information regarding bed availability, wait times, availability of resources, discharge check out arrangements, insurance authorization processing and the like, included in received system state data 914 to identify and select one or more discharge dispositions that account for the factors and/or to adjust the placement probabilities associated with one or more possible discharge dispositions based on the barriers. For example, even once a patient is ready for discharge, it could take days for an insurance provider to review a patient's medical record to authorize discharged to a post-acute care facility. By the time the process is finished, a bed may not be available in the facility of the patient's choice the discharge. In accordance with this example, the optimization component 602 can employ real-time information included in the system state data 914 regarding bed availability at discharge destination options and expected time to receiving insurance authorization for placement to better predict where a patient will be discharged.”, and
Thomas [0117] “With reference again to FIG. 9, the system state data 914 can include dynamic, real-time information regarding variable conditions associated with the state of the inpatient facility (e.g., hospital) where patients are being discharged from, as well as the state of the discharge destinations where patients are being discharged too, that can influence when and where the patients are discharged. For example, the system state data 914 can include real-time information regarding the operating conditions/contexts of the hospital that vary and can influence when and where a patient is discharged, including information regarding patient flow, bed availability, wait times for beds, and availability of resources (e.g., availability of care providers to assist patients, availability of medical supplies/equipment, availability of transportation services, etc.) and the like. The system state data 914 can also include information regarding the operating conditions/contexts of the respective discharge facilities where patients may be discharged, including information regarding bed availability and demand (e.g., wait times), availability of resources at the respective discharge facilities (e.g., patient needs “xyz” resources at the discharge facility upon arrival but these aren't available, aren't working, have long wait times, etc.) and the like. The system state data 914 can also include real-time information regarding insurance authorization processing, including whether an authorization request is pending, expected time to approval, and the like.”).
Thomas fails to explicitly teach model that is trained to request additional data associated with admissions and additional data retrieved to supplement the historical admission data; to determine additional admission data associated with the admission of the at least one patient that is not included in the message and to request additional data; determine a second medical service provider to request the additional admission data from, the second medical service provider being different from the first medical service provider; request the additional admission data; from a first external computing device associated with the second medical service provider; generate a patient data file; store the patient data file in the at least one database; and transmit to a second external computing device.
Rapaka teaches model that is trained to request additional data associated with admissions and additional data retrieved to supplement the historical admission data (Rapaka [0015] “Using heterogeneous data sources, the machine-learnt classifier automatically classifies the patient population and highlights additional sources of information, which if collected may add the most additional information to better diagnose or treat the patient. In particular, the system evaluates the existing sources of data to make a model prediction of the risk of presence of different pathological conditions. In addition, the model computes the likely probabilities of these different conditions and automatically flags high-risk patients who need priority evaluation from clinical providers.”, and
Rapaka [0017] “In scenarios where the available information leads to an uncertain prediction due to missing information, the model may consider further sources of information (such as other kinds of imaging including stress tests and perfusion imaging, or blood tests for additional biomarkers) to suggest or rank the sources of missing information in order of highest information gained. For each of the different conditions, the model may also evaluate quantitative markers that estimate the degree of severity of the condition. For instance, when it is determined that the coronary arteries have a severe occlusion, the model may automatically calculate markers such as Fractional Flow Reserve and related hemodynamic indices.”);
to determine additional admission data associated with the admission of the at least one patient that is not included in the message and to request additional data (Rapaka [0015] “Using heterogeneous data sources, the machine-learnt classifier automatically classifies the patient population and highlights additional sources of information, which if collected may add the most additional information to better diagnose or treat the patient. In particular, the system evaluates the existing sources of data to make a model prediction of the risk of presence of different pathological conditions. In addition, the model computes the likely probabilities of these different conditions and automatically flags high-risk patients who need priority evaluation from clinical providers.”, and
Rapaka [0017] “In scenarios where the available information leads to an uncertain prediction due to missing information, the model may consider further sources of information (such as other kinds of imaging including stress tests and perfusion imaging, or blood tests for additional biomarkers) to suggest or rank the sources of missing information in order of highest information gained. For each of the different conditions, the model may also evaluate quantitative markers that estimate the degree of severity of the condition. For instance, when it is determined that the coronary arteries have a severe occlusion, the model may automatically calculate markers such as Fractional Flow Reserve and related hemodynamic indices.”);
to request the additional admission data from (Rapaka [0015] “Using heterogeneous data sources, the machine-learnt classifier automatically classifies the patient population and highlights additional sources of information, which if collected may add the most additional information to better diagnose or treat the patient. In particular, the system evaluates the existing sources of data to make a model prediction of the risk of presence of different pathological conditions. In addition, the model computes the likely probabilities of these different conditions and automatically flags high-risk patients who need priority evaluation from clinical providers.”, and
Rapaka [0017] “In scenarios where the available information leads to an uncertain prediction due to missing information, the model may consider further sources of information (such as other kinds of imaging including stress tests and perfusion imaging, or blood tests for additional biomarkers) to suggest or rank the sources of missing information in order of highest information gained. For each of the different conditions, the model may also evaluate quantitative markers that estimate the degree of severity of the condition. For instance, when it is determined that the coronary arteries have a severe occlusion, the model may automatically calculate markers such as Fractional Flow Reserve and related hemodynamic indices.”);
request the additional admission data (Rapaka [0017] “In scenarios where the available information leads to an uncertain prediction due to missing information, the model may consider further sources of information (such as other kinds of imaging including stress tests and perfusion imaging, or blood tests for additional biomarkers) to suggest or rank the sources of missing information in order of highest information gained. For each of the different conditions, the model may also evaluate quantitative markers that estimate the degree of severity of the condition. For instance, when it is determined that the coronary arteries have a severe occlusion, the model may automatically calculate markers such as Fractional Flow Reserve and related hemodynamic indices.”);
Rao teaches determine a second medical service provider and the second medical service provider being different from the first medical service provider (Rao [0007]
“According to an aspect of the present disclosure, a healthcare system maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. Upon receiving a request from a healthcare provider to view information related to a patient, the mapping data is examined to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. The healthcare system then provides access to the identified set of EMRs using a common user interface. Accordingly, the healthcare system facilitates data aggregation from multiple EMR systems.”,
Rao [0045] “Healthcare system 150 examines the mapping data to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. Healthcare system 150 then provides access to the identified set of EMRs using a common user interface (via data link 125). Thus, healthcare provider 120 is facilitated to access EMR data stored in multiple different EMR systems.”);
from a first external computing device associated with the second medical service provider (Rao [0007] “According to an aspect of the present disclosure, a healthcare system maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. Upon receiving a request from a healthcare provider to view information related to a patient, the mapping data is examined to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. The healthcare system then provides access to the identified set of EMRs using a common user interface. Accordingly, the healthcare system facilitates data aggregation from multiple EMR systems.”, and
Rao [0045] “Healthcare system 150 examines the mapping data to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. Healthcare system 150 then provides access to the identified set of EMRs using a common user interface (via data link 125). Thus, healthcare provider 120 is facilitated to access EMR data stored in multiple different EMR systems.”);
generate a patient data file (Rao [0085] FIG. 6A depicts portions of a visit summary data specifying the details of interactions between patients and healthcare providers in one embodiment. FIG. 6B depicts portions of a mapping data specifying the EMR systems linked to healthcare providers in one embodiment. For illustration, the visit summary data and mapping data are assumed to be maintained in the form of tables in data store 270. However, in alternative embodiments, the visit summary data and/or mapping data may be maintained according to other data formats (such as files according to extensible markup language (XML), etc.) and/or using other data structures (such as lists, trees, etc.), as will be apparent to one skilled in the relevant arts by reading the disclosure herein.”);
store the patient data file in the at least one database (Rao [0085] FIG. 6A depicts portions of a visit summary data specifying the details of interactions between patients and healthcare providers in one embodiment. FIG. 6B depicts portions of a mapping data specifying the EMR systems linked to healthcare providers in one embodiment. For illustration, the visit summary data and mapping data are assumed to be maintained in the form of tables in data store 270. However, in alternative embodiments, the visit summary data and/or mapping data may be maintained according to other data formats (such as files according to extensible markup language (XML), etc.) and/or using other data structures (such as lists, trees, etc.), as will be apparent to one skilled in the relevant arts by reading the disclosure herein.); and
transmit to a second external computing device (Rao [0049] “Referring to FIG. 1C, insurance carrier 130 (a third-party different from the first party healthcare system 150 and the second party healthcare provider 120) maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. The EMR data may be stored in healthcare system 150 (via data link 135) and/or enterprise 140 (via data link 143). Upon receiving a request from patient 110 (via data link 113), insurance carrier 130 identifies a set of EMR systems that store a set of EMRs that are linked to healthcare provider 120 and contain information related to patient 110. Insurance carrier 130 then provides (e.g. displayed on a display screen) access to the identified set of EMRs using a common user interface.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the intelligent patient classification system of Thomas with the machine learned information gathering techniques of Rapaka and the cross provider electronic medical record retrieval techniques of Rao. Thomas teaches employing machine learning models trained on historical clinical and non-clinical patient information, including gradient boosting algorithms, to classify admitted patients based on learned correlations and predict patient care outcomes. Rapaka further teaches that when the available patient information is insufficient for a reliable prediction, a machine learned classifier can determine that additional information should be obtained and identify or rank additional sources of information that would provide the greatest improvement in predictive accuracy. Rao teaches identifying healthcare provider associated electronic medical record systems containing patient information and retrieving patient records from multiple provider systems. It would have been obvious to combine these teachings because each reference addresses improving machine learning predictions through more complete patient information, and the combination applies known techniques for obtaining additional patient information from external healthcare systems to Thomas's existing machine learning classification framework, yielding the predictable result of improved classification accuracy and more complete patient records.
Furthermore, one of ordinary skill in the art would have been motivated to incorporate Rao's provider to EMR mapping and multi provider record retrieval into Thomas's patient classification system because patient information is commonly distributed among multiple healthcare providers and electronic medical record systems. As taught by Rapaka, additional patient information may significantly improve prediction quality when the initially available information is incomplete. Rao provides a known mechanism for determining which provider associated electronic medical record systems contain the desired patient information and retrieving that information, while Thomas teaches incorporating additional patient information into machine learning predictions and utilizing the resulting predictions within patient care and insurance authorization workflows. Combining these well known techniques would have represented nothing more than the predictable use of prior art elements according to their established functions to improve the accuracy and efficiency of automated patient admission classification and associated healthcare management activities.
Regarding claim 2, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the message comprises an admission discharge transfer (ADT) message (Thomas [0074] “The demographics data 212 can include several demographic features about a patient, such as those provided in admit, discharge and transfer (ADT) feeds, EHR databases and systems, admission forms, and the like. Some non-clinical features included in the demographics data 212 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: patient age, gender, height, weight, body mass index (BMI), ethnicity/race, religion, language, marital status, nationality, birth location (e.g., country, state and/or city), and current residence location (e.g., country, state and/or city).”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the intelligent classification computing system such that the message comprises an admission, discharge, and transfer (ADT) message. Thomas teaches using demographic and clinical data provided via ADT feeds as input to machine learning models for patient classification. A PHOSITA would have been motivated to use ADT messages because they are a standardized, well known mechanism for conveying admission information in healthcare systems and provide predictable results when used as input for admission classification.
Regarding claim 4, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the ML model utilizes a factor selected from the group consisting of state, facility, age, sex, health plan, diagnosis (dx) code, visit duration, product, expected due date, inpatient future risk, risk score, inpatient stay probability, er risk score, nest score, ADT type, trimester 1 visit date, trimester 2 visit date, trimester 3 visit date, Clinical Classifications Software Refined, plan type, source, total BH risk score, er risk score fc, ip risk score, total risk score, and combinations thereof (Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”) and Thomas [0074] “The demographics data 212 can include several demographic features about a patient, such as those provided in admit, discharge and transfer (ADT) feeds, EHR databases and systems, admission forms, and the like. Some non-clinical features included in the demographics data 212 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: patient age, gender, height, weight, body mass index (BMI), ethnicity/race, religion, language, marital status, nationality, birth location (e.g., country, state and/or city), and current residence location (e.g., country, state and/or city).”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the machine learning model to utilize demographic, clinical, and administrative factors such as patient age, sex, diagnosis codes, health plan information, visit duration, and risk scores. Thomas teaches using a wide range of clinical and non clinical features as inputs to machine learning patient classification models. Selecting and combining these known factors represents a routine choice for improving model performance and would have been predictable to a PHOSITA.
Regarding claim 6, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the ML model utilizes a factor selected from the group consisting of age, facility, sex, inpatient future risk, cars, diagnosis code, health plan, ADT type, and combinations thereof (Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”, and Thomas [0074] “The demographics data 212 can include several demographic features about a patient, such as those provided in admit, discharge and transfer (ADT) feeds, EHR databases and systems, admission forms, and the like. Some non-clinical features included in the demographics data 212 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: patient age, gender, height, weight, body mass index (BMI), ethnicity/race, religion, language, marital status, nationality, birth location (e.g., country, state and/or city), and current residence location (e.g., country, state and/or city).”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the ML model to utilize factors such as age, facility, sex, diagnosis code, health plan, ADT type, and inpatient risk scores. Thomas teaches using demographic, clinical, and administrative data derived from ADT feeds and EHR systems as input features to machine learning classification models. Selecting these commonly available patient and admission attributes represents a routine and predictable choice to improve classification accuracy.
Regarding claim 7, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the ML model employs a neural network selected from the group consisting of a convolutional neural network, a deep learning neural network, a combined learning module, a program that learns in two or more fields or areas of interest, and combinations thereof (Thomas [0035] “In various embodiments, the disclosed patient care outcome forecasting techniques employ and an ensemble machine learning approach that involves chaining and/or stacking of a plurality of different predictive models that respectively predict the patient care outcomes based on different combinations of clinical and/or non-clinical factors and/or using different weighting schemes for one or more of the input parameters. For example, with respect to forecasting discharge destinations and associate placement probabilities, the different predictive models can include a first model that forecasts discharge destinations based on a first set of clinical and/or non-clinical factors, a second model that forecast discharge destinations based on a second set of clinical and/or non-clinical factors, a third model that forecast discharge destinations based on a third set of clinical and/or non-clinical factors, and so on. In some implementations, the different discharge forecasting models can also include models that employ different types of machine learning algorithms/models (e.g., neural network models, decision tree models, random forest models, k-means models, etc.).”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to employ neural network models, including deep learning or combined learning modules, within the ML model. Thomas teaches using various machine learning techniques, including neural networks and ensemble approaches, for predicting patient outcomes and classifications. Choosing among known neural network architectures constitutes a routine substitution of known algorithms to achieve predictable results in data classification.
Regarding claim 8, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the ML model is configured for pattern recognition and/or predictive modeling (Thomas [0035] “In various embodiments, the disclosed patient care outcome forecasting techniques employ and an ensemble machine learning approach that involves chaining and/or stacking of a plurality of different predictive models that respectively predict the patient care outcomes based on different combinations of clinical and/or non-clinical factors and/or using different weighting schemes for one or more of the input parameters. For example, with respect to forecasting discharge destinations and associate placement probabilities, the different predictive models can include a first model that forecasts discharge destinations based on a first set of clinical and/or non-clinical factors, a second model that forecast discharge destinations based on a second set of clinical and/or non-clinical factors, a third model that forecast discharge destinations based on a third set of clinical and/or non-clinical factors, and so on. In some implementations, the different discharge forecasting models can also include models that employ different types of machine learning algorithms/models (e.g., neural network models, decision tree models, random forest models, k-means models, etc.).”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the ML model for pattern recognition and predictive modeling. Thomas teaches machine learning models that identify patterns and generate predictions based on clinical and nonclinical factors. Applying these known ML techniques to admission classification is a predictable use of established technology for its intended purpose.
Regarding claim 9, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the at least one processor is further configured to produce a further output based on the automatic classification of the admission (Thomas [0058] “With reference again to FIG. 1A in view of FIG. 1B, the reporting component 116 can further facilitate providing output data 120 regarding the predicted care outcomes 122, (e.g., including the discharge destination forecasts 130, the discharge time/LOS forecasts 136, the readmission risk forecasts 142, and the safety risk forecasts 148) to one or more relevant entities (e.g., systems, devices, applications, etc.) as the predicated care outcome information is generated in real-time. The output data 120 can be reported using various suitable data structures (e.g., as machine readable text, as human readable text, as a graphical visualization, etc.) and/or electronic rendering applications. For example, in some embodiments, the reporting component 116 (and/or the discharge planning module 108) can be integrated with or be coupled to one or more applications that provide various features and/or functionalities associated with optimizing care delivery and/or discharge planning. For instance, in one implementation, the application can include care delivery optimization application accessible via a network-based platform (e.g., a web-application, a website, a thin client application), a centralized command center, or another suitable operating environment. The display component 118 can further provide one or more tiles reporting the output data 120 in real-time.”, Thomas [0132] “One or more embodiments can be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”, Thomas [0083] “In this regard, in some implementations, the complex patient identification component 402 can determine whether a currently admitted patient is a complex needs patient (or not) based on their forecasted discharge destination(s) and placement probability. For example, certain defined discharge destinations can be associated with complex needs patients. In one implementation of this embodiment, the complex needs patient identification component 402 can classify all patients that receive a predicted discharge destination to one that is associated with complex needs patients, as complex needs patients. For example, the complex patient identification component 402 can classify all patients that receive a forecasted discharge destination to a LTAC disposition as complex needs patients based on previously defined information associating the LTAC disposition with complex needs patients. In another implementation, the complex patient identification component 402 can also determine whether a patient is a complex needs patient based on whether the predicted probability of the patient being discharged to a disposition included in the complex needs group is above a defined probability threshold. For example, the complex patient identification component 402 can classify all patients that receive a forecasted discharge destination to a LTAC disposition with a probability of 70% or higher as complex needs patients based on previously defined information associating the LTAC.” and Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to produce additional outputs based on the automatic classification of the admission. Thomas teaches generating and reporting downstream outputs, such as forecasts, risk scores, and classifications, to other systems or user interfaces once patient classification is performed. Providing further outputs based on classification results is a routine post processing step that yields predictable results.
Claims 11 and 18 are analogous to claim 1, thus claims 11 and 18 are similarly analyzed and rejected in a manner consistent with the rejection of claim 1.
Claims 12 and 19 are analogous to claim 2, thus claims 12 and 19 are similarly analyzed and rejected in a manner consistent with the rejection of claim 2.
Claim 14 is analogous to claim 4, thus claim 14 is similarly analyzed and rejected in a manner consistent with the rejection of claim 4.
Claims 16-17 are analogous to claims 6-7, thus claims 16-17 are similarly analyzed and rejected in a manner consistent with the rejection of claims 6-7.
Regarding claim 21, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach the IC computing system, wherein the at least one processor is further configured to (Thomas [0132] “One or more embodiments can be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”):
receive the historical admission data associated with the historical admissions (Thomas [0051] “Thus, in various embodiments, the one or more discharge destination forecasting models 126 can include previously trained/developed models. For example, the one or more discharge destination forecasting models 126 can include one or more models trained on training data including same or similar clinical and non-clinical features included in the input data 104 and recorded discharge information (e.g., discharge document files) identifying actual discharge dispositions where the patients represented in the training data were discharged. It should be appreciated that the model training process can vary based on the type machine learning algorithms employed by the respective discharge destination forecasting models 126, which can vary. For example, some suitable machine learning algorithms/models that can be used for the one or more discharge destination forecasting models 126 can include but are not limited to: a nearest neighbor algorithm, a naïve Bayes algorithm, a decision tree algorithm, a boosting algorithm, a gradient boosting algorithm, a linear regression algorithm, a neural network algorithm, a k-means clustering algorithm, an association rules algorithm, a q-learning algorithm, a temporal difference algorithm, a deep adversarial network algorithm, or a combination thereof. As described in greater detail infra with reference to FIGS. 6-8, in some embodiments, the one or more discharge forecasting models 126 can include a plurality of different models respectively configured to process different types of input parameters, employ different machine learning algorithms, and/or provide different biases toward certain patient groups. In some embodiments, (discussed in greater detail infra with reference to FIG. 13), the one or more discharge destination forecasting models 126 can also be regularly updated/optimized over time based on the input data 104 and discharge information indicating the actual destinations where the patients were actually discharged, as well as user feedback regarding identified discharge barriers for certain patients (e.g., using one or more supervised and/or unsupervised machine learning mechanisms).”);
identify at least one portion of historical data associated with at least one historical admission of the historical admissions, wherein the at least one portion of historical data is not included in the historical admission data (Rapaka [0015] “Using heterogeneous data sources, the machine-learnt classifier automatically classifies the patient population and highlights additional sources of information, which if collected may add the most additional information to better diagnose or treat the patient. In particular, the system evaluates the existing sources of data to make a model prediction of the risk of presence of different pathological conditions. In addition, the model computes the likely probabilities of these different conditions and automatically flags high-risk patients who need priority evaluation from clinical providers.”, and
Rapaka [0017] “In scenarios where the available information leads to an uncertain prediction due to missing information, the model may consider further sources of information (such as other kinds of imaging including stress tests and perfusion imaging, or blood tests for additional biomarkers) to suggest or rank the sources of missing information in order of highest information gained. For each of the different conditions, the model may also evaluate quantitative markers that estimate the degree of severity of the condition. For instance, when it is determined that the coronary arteries have a severe occlusion, the model may automatically calculate markers such as Fractional Flow Reserve and related hemodynamic indices.”);
determine a computing device associated with the at least one portion of historical data (Rao [0007] “According to an aspect of the present disclosure, a healthcare system maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. Upon receiving a request from a healthcare provider to view information related to a patient, the mapping data is examined to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. The healthcare system then provides access to the identified set of EMRs using a common user interface. Accordingly, the healthcare system facilitates data aggregation from multiple EMR systems.”, and
Rao [0045] “Healthcare system 150 examines the mapping data to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. Healthcare system 150 then provides access to the identified set of EMRs using a common user interface (via data link 125). Thus, healthcare provider 120 is facilitated to access EMR data stored in multiple different EMR systems.”);
transmit a request for the at least one portion of historical data to the computing device (Rapaka [0017] “In scenarios where the available information leads to an uncertain prediction due to missing information, the model may consider further sources of information (such as other kinds of imaging including stress tests and perfusion imaging, or blood tests for additional biomarkers) to suggest or rank the sources of missing information in order of highest information gained. For each of the different conditions, the model may also evaluate quantitative markers that estimate the degree of severity of the condition. For instance, when it is determined that the coronary arteries have a severe occlusion, the model may automatically calculate markers such as Fractional Flow Reserve and related hemodynamic indices.”, and
Rao [0007] “According to an aspect of the present disclosure, a healthcare system maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. Upon receiving a request from a healthcare provider to view information related to a patient, the mapping data is examined to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. The healthcare system then provides access to the identified set of EMRs using a common user interface. Accordingly, the healthcare system facilitates data aggregation from multiple EMR systems.”);
receive the at least one portion of historical data (Rao [0007] “According to an aspect of the present disclosure, a healthcare system maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. Upon receiving a request from a healthcare provider to view information related to a patient, the mapping data is examined to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. The healthcare system then provides access to the identified set of EMRs using a common user interface. Accordingly, the healthcare system facilitates data aggregation from multiple EMR systems.”, and
Rao [0045] “Healthcare system 150 examines the mapping data to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. Healthcare system 150 then provides access to the identified set of EMRs using a common user interface (via data link 125). Thus, healthcare provider 120 is facilitated to access EMR data stored in multiple different EMR systems.”, and
Thomas [0110] “In some embodiments, the optimization component 602 can receive additional input data 910 including user feedback data 912 and/or system state data 914 to facilitate determining optimized discharge destination forecasts and/or optimized discharge time forecasts. The user feedback data 912 can include information relevant to a patient's discharge provided by one or more individuals involved in the patient's care (e.g., a care provider, a case worker, a family member, a friend, the patient, etc.). For example, the user feedback data 912 can include user reported information identifying barriers to discharge including clinical and non-clinical tasks to be performed and/or scheduled prior to discharge, during discharged and/or following discharge (e.g., arranging dialysis, scheduling a consult, arranging/scheduling transportation, managing dietary requirements, setting up medication delivery, etc.). The user feedback data 912 can also include information regarding completed tasks and/or discharge milestones. The user feedback data 912 can include contextual information regarding arranging and performing check out of the patient from the hospital, including information regarding who will be accompanying the patient away from the hospital, when they will be arriving, how they will be transporting the patient, and the like.”); and
train the ML model based upon the historical admission data and the at least one portion of historical data, the at least one portion of historical data included in the historical additional data (Thomas [0051] “Thus, in various embodiments, the one or more discharge destination forecasting models 126 can include previously trained/developed models. For example, the one or more discharge destination forecasting models 126 can include one or more models trained on training data including same or similar clinical and non-clinical features included in the input data 104 and recorded discharge information (e.g., discharge document files) identifying actual discharge dispositions where the patients represented in the training data were discharged. It should be appreciated that the model training process can vary based on the type machine learning algorithms employed by the respective discharge destination forecasting models 126, which can vary. For example, some suitable machine learning algorithms/models that can be used for the one or more discharge destination forecasting models 126 can include but are not limited to: a nearest neighbor algorithm, a naïve Bayes algorithm, a decision tree algorithm, a boosting algorithm, a gradient boosting algorithm, a linear regression algorithm, a neural network algorithm, a k-means clustering algorithm, an association rules algorithm, a q-learning algorithm, a temporal difference algorithm, a deep adversarial network algorithm, or a combination thereof. As described in greater detail infra with reference to FIGS. 6-8, in some embodiments, the one or more discharge forecasting models 126 can include a plurality of different models respectively configured to process different types of input parameters, employ different machine learning algorithms, and/or provide different biases toward certain patient groups. In some embodiments, (discussed in greater detail infra with reference to FIG. 13), the one or more discharge destination forecasting models 126 can also be regularly updated/optimized over time based on the input data 104 and discharge information indicating the actual destinations where the patients were actually discharged, as well as user feedback regarding identified discharge barriers for certain patients (e.g., using one or more supervised and/or unsupervised machine learning mechanisms).”, and
Thomas [0006] “In some implementations, the non-clinical data points comprise information regarding post-discharge patient support, including individuals responsible for caring for the respective patients after their discharge from the hospital, such as friends, family members, home care assistants, and the like. The non-clinical data points can also comprise information regarding patient socioeconomic status (e.g., income level, standard of living, tax bracket, profession, etc.). The non-clinical data points can also comprise patient demographic information (e.g., age, gender, ethnicity, home location, religion, marital status, etc.), and patient insurance information. The clinical data points can include both historical medical information about a patient received from one or more existing databases (e.g., electronic health record (EHR) databases) as well as clinical data collected for a patient from various data sources in real-time over the course of their inpatient stay.”,
Rao [0007] “According to an aspect of the present disclosure, a healthcare system maintains mapping data specifying the Electronic Medical Record (EMR) systems at which EMRs linked to healthcare providers are stored, each EMR containing information related to a corresponding patient. Upon receiving a request from a healthcare provider to view information related to a patient, the mapping data is examined to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. The healthcare system then provides access to the identified set of EMRs using a common user interface. Accordingly, the healthcare system facilitates data aggregation from multiple EMR systems.”, and
Rao [0045] “Healthcare system 150 examines the mapping data to identify a set of EMR systems that store a set of EMRs that are linked to the healthcare provider and contain information related to the patient. Healthcare system 150 then provides access to the identified set of EMRs using a common user interface (via data link 125). Thus, healthcare provider 120 is facilitated to access EMR data stored in multiple different EMR systems.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the machine learning model training techniques of Thomas with the additional information identification techniques of Rapaka and the distributed electronic medical record retrieval techniques of Rao. Thomas teaches training and continually updating machine learning models using historical clinical and non-clinical patient data, including historical medical information, recorded discharge information, and additional patient features to improve predictive performance. Rapaka further teaches that when available information is incomplete, a machine learned classifier can identify additional sources of information that would provide the greatest informational benefit to improve prediction accuracy. Rao teaches identifying the electronic medical record systems associated with healthcare providers, requesting and retrieving patient information from those distributed electronic medical record systems, and aggregating the retrieved patient information from multiple sources. One of ordinary skill in the art would have been motivated to incorporate Rapaka's technique for identifying additional relevant information and Rao's distributed electronic medical record retrieval mechanism into Thomas's machine learning training framework in order to supplement the historical training data with additional historical patient information from multiple healthcare provider systems. Doing this would have predictably improved the completeness and quality of the training dataset, which improves the resulting predictive accuracy of the trained machine learning model through the predictable use of prior art elements according to their established functions.
Claims 3, 5, 13, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas et al. (U.S. Patent Publication 2021/0098090 A1), referred to hereinafter as Thomas, in view of Rapaka et al. (U.S. Patent Publication 2018/0315182 A1) referred to hereinafter as Rapaka, and Rao et al. (U.S. Patent Publication 2020/0321086 A1) referred to hereinafter as Rao, and further in view of Ellis et al (Ellis et al., Development and Assessment of a New Framework for Disease Surveillance, Prediction, and Risk Adjustment, The Diagnostic Items Classification System, JAMA Health Forum, 3(3), pg: 1-12 (Year: 2022)), referred to hereinafter as Ellis.
Regarding claim 3, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the plurality of admission types comprises at least one admission type (Thomas [0074] “The demographics data 212 can include several demographic features about a patient, such as those provided in admit, discharge and transfer (ADT) feeds, EHR databases and systems, admission forms, and the like. Some non-clinical features included in the demographics data 212 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: patient age, gender, height, weight, body mass index (BMI), ethnicity/race, religion, language, marital status, nationality, birth location (e.g., country, state and/or city), and current residence location (e.g., country, state and/or city).”).
Thomas, Rapaka, and Rao fail to explicitly teach selected from the group consisting of an obstetrics (GB) type, a behavioral health (BH) type, and a Medical type.
Ellis teaches selected from the group consisting of an obstetrics (GB) type, a behavioral health (BH) type, and a Medical type (Ellis, page 7, “Table 3 compares the DXI model to the HCC and CCSR models in numbers of regressors, both overall and those which are statistically significant (P < .001). For example, across the eye, ear, and skin disease chapters—comprising more than 4000 diagnoses in total—the FY2018 HCC model recognized only 1 disease category, and the CCSR recognizes 25 categories, while our DXI system uses 378 DXIs. Other chapters with large increases in the numbers of significant coefficients are infectious and parasitic diseases, blood disorders, diseases of the nervous system, and musculoskeletal conditions.”, and Ellis, page 8, Table 3, “5 F01-F99 MBD Mental, behavioral, and neurodevelopmental disorders” and 15 O00-O9A PRG Pregnancy, childbirth, and the puerperium”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to classify admissions into obstetrics, behavioral health, and medical admission types. Thomas teaches classifying admitted patients using machine learning models based on clinical and demographic data, and Ellis teaches organizing diagnoses into clinically meaningful categories including behavioral health and pregnancy related conditions. A PHOSITA would have been motivated to apply these known clinical groupings to admission classification in order to improve accuracy and standardization, yielding predictable results.
Regarding claim 5, Thomas, Rapaka, and Rao teach the invention in claim 1, as discussed above, and further teach wherein the ML model utilizes a factor selected from (Thomas [0085] “The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.”).
Thomas, Rapaka, and Rao fail to explicitly teach the group consisting of trimester 1 visit date, trimester 2 visit date, trimester 3 visit date, and combinations thereof.
Ellis teaches the group consisting of trimester 1 visit date, trimester 2 visit date, trimester 3 visit date, and combinations thereof (Ellis, page 7, “Table 3 compares the DXI model to the HCC and CCSR models in numbers of regressors, both overall and those which are statistically significant (P < .001). For example, across the eye, ear, and skin disease chapters—comprising more than 4000 diagnoses in total—the FY2018 HCC model recognized only 1 disease category, and the CCSR recognizes 25 categories, while our DXI system uses 378 DXIs. Other chapters with large increases in the numbers of significant coefficients are infectious and parasitic diseases, blood disorders, diseases of the nervous system, and musculoskeletal conditions.”, Ellis, page 8, Table 3, “15 O00-O9A PRG Pregnancy, childbirth, and the puerperium”, Ellis, page 5, “Figure 1 provides a schematic framework for mapping individual ICD-10-CM codes to DXIs, illustrating the precision in classification enabled by the ICD-10-CM system.” and “First trimester, second trimester, and third trimester” (Figure 1, C)).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to utilize trimester specific visit timing as an input factor to the machine learning model. Ellis teaches distinguishing pregnancy related diagnoses and conditions by trimester, and Thomas teaches incorporating temporal and clinical features into machine learning based classification. A PHOSITA would have been motivated to include trimester timing as a known, relevant factor for obstetric admission classification, with a reasonable expectation of improved classification accuracy.
Claims 13 and 20 are analogous to claim 3, thus claims 13 and 20 are similarly analyzed and rejected in a manner consistent with the rejection of claim 3.
Claim 15 is analogous to claim 5, thus claim 15 is similarly analyzed and rejected in a manner consistent with the rejection of claim 5.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted on 04/29/2026 with respect to the rejection of the claims have been carefully considered and is addressed below.
Claim Rejections - 35 USC § 101
Applicant's arguments have been fully considered but are not persuasive. Applicant states that the claims do not recite a mental process because the recited machine learning (ML) model performs actions that cannot practically be performed in the human mind (USPTO Memorandum of August 4, 2025). However, the rejection is not based on the mathematical operations or implementation of the recited gradient boosted decision tree model. Instead, under the broadest reasonable interpretation, the claim recites analyzing the admission information to determine additional admission information, determining a source from which to request the additional admission information, generating a predicted classification defining a reason for the admission, and classifying the admission into an admission type. These limitations recite observations, evaluations, and judgments that can practically be performed in the human mind or with the aid of pen and paper. The recitation of the processor, external computing devices, and machine learning model uses generic computer components used as tools to perform these evaluations and judgments and does not remove the claim from the mental processes grouping.
Applicant further states that the claims integrate the judicial exception into a practical application because the specification identifies technical problems and technical effects, such as reducing misclassifications, reducing wasted resources, improving workflows, and requesting additional admission data. These arguments are not persuasive because the improvements are directed to improving the accuracy and efficiency of the underlying admission classification and healthcare authorization process rather than improving the functioning of a computer, machine learning technology, or another technological field. While the specification discusses improved classification performance and workflow efficiencies, the claims implement the abstract idea using generic computer components performing their ordinary functions of processing and requesting information. Accordingly, the additional elements do not impose a meaningful limit on the judicial exception or integrate the exception into a practical application.
Applicant's arguments regarding Step 2B have also been considered but are not persuasive. The additional elements, individually and as an ordered combination, perform well-understood, routine, and conventional computer functions of receiving, storing, and transmitting information. Similar to In re Brown, 645 F. App'x 1014, 1016-17 (Fed. Cir. 2016), generating a patient data file and authorization message, storing the patient data file, and transmitting the authorization message constitute insignificant post-solution activity that records and communicates the results of the abstract mental process. Also, similar to the claims found in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742-43 (Fed. Cir. 2016), the claims are directed to collecting information, analyzing the information, and using the results of the analysis. The additional elements of receiving admission data and request and receive additional admission data for use in the analysis gather information before performing the abstract analysis, without improving the functioning of a computer or any other technology. Accordingly, the additional elements do not amount to significantly more than the judicial exception, and the rejection under 35 U.S.C. § 101 is therefore maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments traversing the prior art rejection in the previous Office Action have been fully considered. However, those arguments are rendered moot because the present rejection under 35 U.S.C. §103 relies on a different set of prior art references (Thomas, Rapaka, and Rao or Thomas, Rapaka, Rao, and Ellis), which teach or suggest the limitations of the claims. Accordingly, Applicant’s prior arguments are not responsive to the current grounds of rejection. The rejection of claims 1-9, and 11-21 under 35 U.S.C. §103 is therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure.
Sutton et al. (U.S. Patent 11967433B1) teaches a method and system that uses a machine learning model trained on historical EMR data and real time HL7 clinical data to estimate, in real time or near real time, a hospital emergency department patient’s risk of a cardiac event.
Roder et al. (U.S. Publication 2022/0188701 A1) teaches a machine learning diagnostic architecture that efficiently computes Shapley values to explain and interpret individual patient predictions, making clinical classifiers useful for treatment decision support.
Hindo et al. (U.S. Publication 2011/0029322 A1) teaches an automated system that determines authorization for a medical procedure using patient symptoms and diagnosis data received via a user interface or database, and provides the authorization outcome through the user interface.
Saha et al. (Saha et al., Using hospital Admission, Discharge & Transfer (ADT) data for predicting readmissions, (2021), Machine Learning with Applications 5, 1-9 (Year: 2021)) teaches using machine learning on real-time ADT data that improves hospital readmission prediction.
Rumoro (International Publication No. WO-2018160929-A1) teaches machine-learning based systems for predicting various aspects of a patient’s hospital stay, including admission, discharge, and length of stay by processing initial patient data, segments it into relevant categories, and uses predictive modelling to compare it with historical patterns.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kambiz Abdi can be reached at (571)272-6702. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685
Prosecution Insights