DETAILED CORRESPONDENCE
This is a non-final office action on merits in response to the arguments and/or amendments filed on 10/16/2025 and the request for continued examination filed on 10/16/2025.
Notice of Pre-AIA or AIA Status
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
Claim 10 is cancelled. Amendments to claims 1, 11, and 18 are acknowledged and have been carefully considered. Claims 1-9, and 11-21 are pending and considered below.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/14/2025 has been entered.
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 determine additional admission data associated with the admission of the at least one patient that is not included in the message; request 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; 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 and an authorization message associated with the admission of the at least one patient. These limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind or by using a pen and paper. But for the “the ML model is configured to” language, the claim encompasses a user simply evaluating the available admission information, identifying missing information, requesting additional information, making a determination about the type of admission and whether authorization should be generated in their mind or by using a pen and paper. The mere nominal recitation of “the ML model is configured to” do not take the claim limitations 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:
receive a message including admission data associated with an admission of at least one patient;
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 based upon receipt of the admission data, the ML model is configured to:
determine additional admission data associated with the admission of the at least one patient that is not included in the message;
request and receive, from a first external computing device, 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;
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 classifying an admission and determining whether to generate an authorization based on available admission information in a computer environment. The claimed computer components (i.e., configure the admission data into input data for a machine learning (ML) model configured to automatically classify the data by admission type, wherein based upon receipt of the admission data, the ML model is configured to, from a first external computing device, generate a patient data file, and store the patient data file in the at least one database) are recited at a high level of generality and are merely invoked as tools to perform an existing process of evaluating admission information, identifying missing information, and making a classification and authorization determination. 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 receive a message including admission data associated with an admission of at least one patient, input the input data into the ML model, receive the additional admission data, and transmit 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 and transmitting data in support of an admission classification and authorization determination), and amounts to merely data gathering and insignificant application, which is a form of insignificant extra-solution activity. 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 classifying an admission and determining whether to generate an authorization based on available admission information 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 receive a message including admission data associated with an admission of at least one patient, input the input data into the ML model, receive the additional admission data, and transmit 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 subsequent processing, which represents a well-understood, routine, and conventional activity in the field of clinical data 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 [0045] and [0059]). 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 transmitting the authorization message to a second external computing device for approval represents an insignificant application of the underlying mental process, as the transmission simply communicates the result of the determination 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-8, 12-17, 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 9 and 21 recite the additional elements of at least one processor is further configured to produce a further output based on the automatic classification of the admission (claim 9), receive historical admission data associated with a plurality of historical admissions (claim 21), receive the at least one portion of historical data (claim 21), and train the ML model based upon the historical admission data and the at least one portion of historical data (claim 21). However, these additional element amounts to implementing an abstract idea on a generic computing device or mere data gathering (i.e., an insignificant extra-solution activity)). 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 claim is 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 Otten et al. (U.S. Patent Publication 2024/0143707 A1), referred to hereinafter as Otten.
Regarding claim 1, Thomas teaches an intelligent classification (IC) computing system comprising at least one processor in communication with at least one database (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.”), the at least one processor 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 a message including admission data associated with an admission of at least one patient (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 [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.”);
input the input data into the ML model, wherein based upon receipt of the admission data, the ML model is configured to (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.”):
determine additional admission data associated with the admission of the at least one patient that is not included in the message (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.”);
request and receive, from a first external computing device, 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.”, Thomas [0112] “For example, FIG. 10 presents an example GUI 1000 that facilitates receiving user feedback data 912 regarding patient discharge barriers and milestones in accordance with one or more embodiments of the disclosed subject matter. In various embodiments, GUI 1000 is an example GUI that can be generated and/or provided by the feedback component 908 and/or the display component 118 to facilitate coordinating patient care and capturing user feedback (e.g., user feedback data 912) regarding patient care needs, barriers to discharge, and the like.”); 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 (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 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 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.”, Thomas [0088] “In some embodiments, the complex patient identification component 402 can also employ machine learning methods, qualitative methods, or hybrid techniques to identify relevant clinical factors collected for a currently admitted patient (e.g., via the data collection component 112) that strongly influence the patient being classified as complex needs and/or that require clinical attention (e.g., during the patient stay and/or post-discharge). For example, the complex patient identification component 402 can identify specific care needs of the complex patient that significantly contribute (e.g., relative to other factors) to them being classified as complex (e.g., needing hemodialysis, chemotherapy, radiation therapy, wound vacuums, and mental health care needs, having a physical disability, etc.). In another example, the complex patient identification component 402 can identify clinical factors that require coordination and scheduling for the complex needs patient during and/or post-discharge (e.g., the patient needs dialysis before and after discharge along with nursing support, the patient needs oxygen before and after discharge along with equipment support etc.). These relevant factors can be predefined and/or learned using one or more machine learning techniques. In some implementations, these strong contributing factors can be given higher weight in the complex needs classification model.”);
based upon automatically classifying the admission, generate a patient data file associated with the admission of the at least one patient (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 [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).”); and
store the patient data file in the at least one database (Thomas [0060] “In this regard, the deployment architecture of system 100 and other systems described herein can vary. For example, various features and functionalities of system 100 (and additional systems described herein) can be deployed using a distributed computing environment, wherein the one or more devices, sources, modules and/or components of system 100 (and other systems described herein) can be provided in a distributed manner across various interconnected (via one or more networks) systems and devices (e.g., internal systems, the cloud, two or more dedicated servers, etc.). For example, system 100 can be deployed in a cloud architecture, a virtualized enterprise architecture, or an enterprise architecture wherein one the front-end components and the back-end components are distributed in a client/server relationship. With these embodiments, one or more features and functionalities of the system 100 can be deployed as a web-application, a cloud-application, a thin client application, a thick client application, a native client application, a hybrid client application, or the like, wherein one or more of the front-end components (e.g., reporting component 116) are provided at client device (e.g., the one or more user devices 122) and one or more of the back-end components (e.g., the data collection component 112, care outcomes forecasting component 114, etc.) are provided in the cloud, on a virtualized server, a virtualized data store, a remote server, a remote data store, a local data center, etc., and accessed via a network (e.g., the Internet). In this regard, the patient input data systems/sources 102, the patient discharge planning module 110, one or more components of the patient discharge planning module 110, and/or the one or more user devices 122 can be physically separated yet communicatively coupled via one or more networks. However, it should be appreciated however that system 100 is not limited to this architectural configuration. For example, in another embodiment, the entirety of the patient discharge planning module 110 can be deployed on a single local device (e.g., a desktop computer) as a local web-based application.”).
Thomas fails to explicitly teach an authorization message; and transmit the authorization message to a second external computing device for approval.
Otten teaches an authorization message (Otten [0020] “In accordance with a further aspect of the invention there is provided a computer program product for remote authorisation, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, from a remote computing device, a claim request message including a set of event data elements relating to an event and a client profile identifier: initiating initial processing of a claim associated with the event including: using the event data elements to determine a category indicator with which the event is associated; and, if the event is associated with a first category indicator, provisionally authorising the claim and transmitting a provisional authorisation confirmation message to one or both of the remote computing device and a client communication device for initiating emergent mitigation of a condition or consequence associated with the event.”);
transmit the authorization message to a second external computing device for approval (Otten [0020] “In accordance with a further aspect of the invention there is provided a computer program product for remote authorisation, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, from a remote computing device, a claim request message including a set of event data elements relating to an event and a client profile identifier: initiating initial processing of a claim associated with the event including: using the event data elements to determine a category indicator with which the event is associated; and, if the event is associated with a first category indicator, provisionally authorising the claim and transmitting a provisional authorisation confirmation message to one or both of the remote computing device and a client communication device for initiating emergent mitigation of a condition or consequence associated with the event.” And Otten [0033] “A system and method for remote authorization are provided herein. Aspects of the present disclosure relate to a remote authorisation system and method using an “admission matrix”, or assessment model, and “triage”, or categorisation, according to which the severity of an event (e.g. an injury) can be determined and/or whether or not such an event should result in an admission. An admission triggers a certain benefit in an insurance product (and hence incurs an increased cost of claim for the insurance provider). The admission matrix described herein is configured for use in establishing an authorisation (or approval) cover type indicator (e.g. consultation/illness/accident) associated with the event and stipulating the type of cover under which treatment of the event will be covered (if any). Aspects of the present disclosure enable near real-time provisional authorisation of claims associated with time-critical events based on category indicator. This may enable emergent mitigation of conditions or consequences associated with the event (including for example treatment of a condition associated with or arising from the event).”).
Therefore, it would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the invention, to modify the machine learning patient admission classification system of Thomas to incorporate the authorization generation and transmission techniques of Otten. Thomas teaches receiving admission data, configuring the data as input to a machine learning model, obtaining additional admission data, and generating a classification output to automatically classify a patient admission. Otten teaches generating an authorization based on a category indicator and transmitting an authorization message to an external computing device for approval. A PHOSITA would have been motivated to combine these teachings because both references address automating healthcare administrative decision making, and Otten provides a known solution for authorization processing that follows from the admission classification results generated by Thomas.
Also, the combination of Thomas and Otten represents the use of known techniques for their established purposes to yield predictable results, which are automated classification of patient admissions followed by automated generation, storage, and transmission of authorization messages. Thomas teaches insurance authorization status and downstream administrative processing, and Otten teaches performing authorization decisions and communications based on categorization outcomes. Applying Otten’s authorization workflow to the classification outputs of Thomas would have been a straightforward and predictable choice for improving efficiency and reducing manual processing in healthcare systems, with a reasonable expectation of success. Accordingly, the claimed intelligent classification computing system would have been obvious to a PHOSITA in view of the combined teachings of Thomas and Otten.
Regarding claim 2, Thomas and Otten 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 and Otten 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 and Otten 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 and Otten 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 and Otten 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 and Otten 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 and Otten teach the invention in claim 1, as discussed above, and further teach 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 historical admission data associated with a plurality of historical admissions (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. For example, the clinical data points can include tracked vital signs, tracked clinical events, tracked patient status and location information, scheduled procedures, and the like. The clinical data can also include information regarding laboratory studies and imaging studies performed, including timing of performance, type of study performed, results, and the like. The clinical data can also include case worker information reported by case workers assigned to the respective patients.”);
identify at least one portion of historical data associated with at least one historical admission of the plurality of historical admissions, the at least one portion of historical data is not included in the historical admission data (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. For example, the clinical data points can include tracked vital signs, tracked clinical events, tracked patient status and location information, scheduled procedures, and the like. The clinical data can also include information regarding laboratory studies and imaging studies performed, including timing of performance, type of study performed, results, and the like. The clinical data can also include case worker information reported by case workers assigned to the respective patients.”);
determine a computing device associated with the at least one portion of historical data (Thomas [0062] “With reference to FIG. 2 in view of FIGS. 1A and 1B, in one or more embodiments, the clinical patient data 106 can be grouped into medical history data 202 and current visit data 204. The medical history data 202 can include medical history information for currently admitted patients and past patients, such as that provided in by one or more EHR databases and systems. For example, the patient medical history information can include internal medical history information for patients associated with a single healthcare organization, as well as medical history information aggregated for patients across various disparate healthcare organizations/vendors (e.g., internal and third-party organizations/vendors) and accessed via a healthcare information exchange system (HIE). Some clinical features included in the medical history data 202 that can be used as input to 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 132 and/or the one or more safety risk forecasting models 144 can include but are not limited to: comorbidities, ongoing illnesses (including mental illnesses), past diagnoses, past hospital stays and associated LOS, past intensive care unit (ICU) stays, past surgeries, regular and acute medications taken, and whether the patient has any implanted medical devices (IMDs) and if so, the type and location of the IMDs.”);
transmit a request for the at least one portion of historical data to the computing device (Thomas [0046] “With reference to FIGS. 1A and 1B, in various embodiments, the data collection component 112 can collect, extract or otherwise receive input data 104 including a variety of defined clinal and non-clinical data points associated with an admitted for input to the respective forecasting models (e.g., the one or more discharge destination forecasting models 126, the one or more LOS forecasting models 132, the one or more readmission risk forecasting models 138, the one or more safety risk forecasting models 144, and the like). The data collection component 112 can collect this input data 104 from various different patient input data systems/sources 102 at the time of admission and continue to collect relevant input data from one or more of these patient input data systems/sources 102 over the course of the patient's inpatient stay (e.g., up until discharge or another defined point in the patient's care). For example, the patient input data systems/sources 102 can include various static and dynamics data sources, including electronic databases, systems or devices that provide patient medical records (e.g., EHRs), patient admission information, patient insurance information, patient demographic information, patient family support information, case worker impression information, clinician reports/notes, imaging study information, laboratory information, tracked patient status information, tracked patient vital signs information, tracked clinical event information (e.g., procedures performed, medications administered, etc.), tracked patient location information, and the like. In some embodiments, the data collection component 112 can extract defined clinical and/or non-clinical parameters (and corresponding values) from the input data 104 using natural language processing (NLP). For example, the data collection component 112 can evaluate medical orders, clinical notes, laboratory reports, imaging study reports, dictations, case worker files, etc., using NLP to identify and extract defined input parameters (and values) for input to the respective care outcome forecasting models.”);
receive the at least one portion of historical data ((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. For example, the clinical data points can include tracked vital signs, tracked clinical events, tracked patient status and location information, scheduled procedures, and the like. The clinical data can also include information regarding laboratory studies and imaging studies performed, including timing of performance, type of study performed, results, and the like. The clinical data can also include case worker information reported by case workers assigned to the respective patients.”); and
train the ML model based upon the historical admission data and the at least one portion of historical 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.”, 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. For example, the clinical data points can include tracked vital signs, tracked clinical events, tracked patient status and location information, scheduled procedures, and the like. The clinical data can also include information regarding laboratory studies and imaging studies performed, including timing of performance, type of study performed, results, and the like. The clinical data can also include case worker information reported by case workers assigned to the respective patients.”)
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the intelligent classification computing system to receive historical admission data, identify missing portions of that historical data, request and receive the missing data from associated computing devices, and train the machine learning model based on the historical admission data and the received additional data. Thomas teaches collecting historical clinical and nonclinical patient data from EHRs and other distributed healthcare systems, identifying relevant data attributes, and continuously training and updating machine learning models using such historical and supplemental data to improve predictive performance. A PHOSITA would have been motivated to request missing historical data and retrain the ML model because doing this is a known and conventional technique for improving model accuracy and reliability, yielding predictable results in patient classification and outcome forecasting.
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 Otten et al. (U.S. Patent Publication 2024/0143707 A1), referred to hereinafter as Otten, 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 and Otten 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 and Otten 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 and Otten 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 and Otten 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 10/16/2025 with respect to the rejection of claims 1-9, and 11-21 have been carefully considered and are addressed below.
Claim Rejections - 35 USC § 101
Applicant’s arguments have been fully considered but are not persuasive. Under Step 2A, Prong One, the claims recite a judicial exception in the form of a mental process. Although Applicant argues that the inclusion of a machine learning (ML) model removes the claims from the mental process grouping, the analysis is based on the broadest reasonable interpretation of the claim limitations, not on recitations of ML. The claims recite steps of evaluating admission information, identifying missing information, requesting additional information, generating a classification, and determining whether to generate an authorization. These steps describe human judgment and decision making that can be practically performed in the human mind or using pen and paper. The claims do not recite any specific ML architecture, algorithm, or technical feature that would render the steps incapable of being performed mentally. Accordingly, the recitation that “the ML model is configured to” does not remove the claims from the mental process grouping.
Under Step 2A, Prong Two, the claims do not integrate the judicial exception into a practical application. Although the specification discusses benefits such as improved accuracy, efficiency, and reduced cost, these are results of improved decision making, not improvements to computer technology itself. The claims do not recite any improvement to the functioning of a computer, to machine learning technology, or to the data processing mechanisms. Instead, the claims merely recite receiving data, configuring data for an ML model, requesting additional data, storing data, and transmitting results using generic processors and databases. These limitations amount to instructions to apply the abstract idea using a computer, data gathering, and insignificant extra solution activity.
Finally, under Step 2B, the claims do not recite significantly more than the judicial exception. The additional elements are well understood, routine, and conventional activities in the field of clinical and administrative data management, and also as acknowledged in the specification. As explained in Electric Power Group, LLC v. Alstom S.A., merely collecting and analyzing information does not add an inventive concept. Additionally, similar to In re Brown, merely transmitting the result of a determination, such as transmitting an authorization message for approval, constitutes an insignificant application of the underlying abstract idea. Accordingly, the claims do not recite an inventive concept. For these reasons, the rejection of claims 1-9 and 11-21 under 35 U.S.C. § 101 is maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments have been considered but are not persuasive. The arguments presented are moot because the current rejection relies on a newly applied combination of Thomas, Otten and Ellis, which collectively teach the claimed subject matter. Accordingly, the claims remain unpatentable under 35 U.S.C. §103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure.
Roder et al. (U.S. Publication 2022/0188701) 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