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 12/15/2025. Amendments to claims 1-3, 5-11, 13-20 are acknowledged and have been carefully considered. Claims 1-20 are pending and considered below.
Claim Rejections - 35 USC § 112
Claims 5, 13, and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The claims recite that the processor is configured to build the ML model by (1) using the unstructured EHR data as training data in a first training stage, and (2) using the structured EHR data as training data in a second training stage. This language requires distinct and sequential training stages in which different categories of data are used in separate stages of model training.
The specification describes that the predictive model may be a machine learning model trained using EHR data, and that EHR data may include structured and unstructured data. However, the specification does not describe or suggest training the ML model in separate stages based on data type, nor does it disclose a first training stage using only unstructured data followed by a second training stage using only structured data. The disclosure generally refers to training the model using EHR data as a whole and does not describe a staged or sequential training architecture based on structured versus unstructured inputs.
Accordingly, the specification does not reasonably convey to a person of ordinary skill in the art that the inventor had possession of the claimed two stage training process at the time of filing. Therefore, claims 5, 13, and 20 fail to comply with the written description requirement of 35 U.S.C. § 112(a).
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-20 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-8 are drawn to an analytics computing device, claims 9-16 are drawn to a computing-implemented method, and claims 17-20 are drawn to at least one non-transitory computer-readable media having computer-executable instructions. 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 9 recites the limitations of parsing, the unstructured EHR data and the metadata to retrieve one or more indicator phrases for the patient, the one or more indicator phrases including at least one environmental risk factor and correlated to an Alzheimer's disease (AD) diagnosis; and identifying the patient as being at risk for AD based on the retrieved indicator phrases and on the structured EHR data. These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover the performance of the limitations in the mind or by using a pen and paper. But for the “using a natural language processing model” or “using the predictive model” language, the claim encompasses a user simply reviewing clinical records, recognizing relevant indicators, and assessing an Alzheimer's disease risk in their mind or by using a pen and paper. The mere nominal recitation of a natural language processing model or the predictive model does 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 1 and 17 recite identical or nearly identical steps with respect to claim 9 and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this claim is therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per method claim 9, include:
retrieving, by the processor, the EHR data from the database;
parsing, using a natural language processing model, the unstructured EHR data and the metadata to retrieve one or more indicator phrases for the patient, the one or more indicator phrases including at least one environmental risk factor and correlated to an Alzheimer's disease (AD) diagnosis;
inputting the retrieved one or more indicator phrases and the structured EHR data for the patient into a predictive model; and
identifying, using the predictive model, the patient as being at risk for AD based on the retrieved indicator phrases and on the structured EHR data.
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 9 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of analyzing clinical information to identify Alzheimer’s disease risk in a computer environment. The claimed computer components (i.e., by the processor, using a natural language processing model, and using the predictive model) are recited at a high level of generality and are merely invoked as tools to perform an existing process of reviewing patient records, identifying relevant disease indicators, and assessing disease risk. 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 9 is not integrated into a practical application. The claim recites the additional elements of retrieving the EHR data from the database and inputting the retrieved one or more indicator phrases and the structured EHR data for the patient into a predictive model. These limitations are recited at a high level of generality (i.e., as a general means of collecting and supplying data for analysis), and amounts to merely data gathering, 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 claim is directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 9 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 reviewing clinical information to identify relevant indicators and making a diagnostic judgement about Alzheimer’s disease risk 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 9, under step 2B, the additional elements of retrieving the EHR data from the database and inputting the retrieved one or more indicator phrases and the structured EHR data for the patient into a predictive model have been evaluated. The computer implemented method comprising a processor 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 analytics and electronic health record processing. 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 [0040]-[0043]). 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 computer implemented method is no more than collecting information before analyzing the data to access Alzheimer’s disease risk and does not integrate the abstract idea into a practical application. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 4, 7, 10, 12, 14-16, 19, 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 2-3, 5-6, 8, 11, 13, 18, and 20 recite the additional element of the processor. However, this additional element amounts to implementing an abstract idea on a generic computing device. As such, this additional element, when considered individually or in combination with the prior devices, does 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kartoun et al. (U.S. Patent Publication 2019/0189253 A1), referred to hereinafter as Kartoun, in view of Spurlock et al. (International Publication No. WO 2019/071098 A2), referred to hereinafter as Spurlock.
Regarding claim 1, Kartoun teaches an analytics computing device comprising a processor in communication with a database, the database configured to store electronic health record (EHR) data including metadata, structured EHR data and unstructured EHR data for a patient, the processor configured to (Kartoun [0075] “FIG. 1 depicts a schematic diagram of one illustrative embodiment of a cognitive system 100 implementing a request processing pipeline 108 in a computer network 102. The cognitive system 100 is implemented on one or more computing devices 104A-D (comprising one or more processors and one or more memories, and potentially any other computing device elements generally known in the art including buses, storage devices, communication interfaces, and the like) connected to the computer network 102.”, Kartoun [0005] “In one illustrative embodiment, a method is provided, in a data processing system comprising at least one processor and at least one memory, the at least one memory comprising instructions executed by the at least one processor to cause the at least one processor to implement a medical condition verification system. The method comprises receiving, by the medical condition verification system, patient electronic medical record (EMR) data, and parsing, by the medical condition verification system, the patient EMR data to identify an instance of a medical code or medical condition indicator present in the patient EMR data. The method further comprises performing, by the medical condition verification system, cognitive analysis of the patient EMR data to identify evidential data supportive of the instance referencing an associated medical condition. Moreover, the method comprises generating, by the medical condition verification system, a measure of risk of the patient having the medical condition based on the identified evidential data and based on a machine learned relationship of medical factors in patient EMR data relevant to generating the measure of risk for the associated medical condition. In addition, the method comprises generating, by the medical condition verification system, an output representing the measure of risk of the patient having the associated medical condition.”, Kartoun [0076] The various computing devices 104A-D on the network 102 include access points for content creators and cognitive system users. Some of the computing devices 104A-D include devices for a database storing the corpus or corpora of data 106 (which is shown as a separate entity in FIG. 1 for illustrative purposes only). Portions of the corpus or corpora of data 106 may also be provided on one or more other network attached storage devices, in one or more databases, or other computing devices not explicitly shown in FIG. 1. The network 102 includes local network connections and remote connections in various embodiments, such that the cognitive system 100 may operate in environments of any size, including local and global, e.g., the Internet.”, and Kartoun [0113] “In the depicted example, the patient EMRs database 322 is a patient information repository that collects patient data from a variety of sources, e.g., hospitals, laboratories, physicians' offices, health insurance companies, pharmacies, etc. The patient EMRs 322 store various information about individual patients, such as patient 302, in a manner (structured, unstructured, or a mix of structured and unstructured formats) that the information may be retrieved and processed by the healthcare cognitive system 300.”, and Kartoun [0030] “That is, each instance of a medical code or medical condition indicator may be separately evaluated and an annotation or metadata specifying the instance of the medical code or medical condition indicator and the results of the medical condition verification system operations may be added to the patient EMR to thereby generate a disambiguated patient EMR.”):
retrieve the EHR data from the database (Kartoun [0076] “The cognitive system 100 is configured to implement a request processing pipeline 108 that receive inputs from various sources. In some illustrative embodiments, the requests may be posed in the form of a natural language question, natural language request for information, natural language request for the performance of a cognitive operation, or the like, or may be posed in the form of a request to perform a cognitive operation on a particular portion of data, e.g., a specified patient EMR, set of patient EMRs, or the like, e.g., “perform disambiguation on John Smith's EMR” or an automated instruction to perform such an operation. For example, the cognitive system 100 receives input from the network 102, a corpus or corpora of electronic documents 106, cognitive system users, and/or other data and other possible sources of input. In one embodiment, some or all of the inputs to the cognitive system 100 are routed through the network 102. The various computing devices 104A-D on the network 102 include access points for content creators and cognitive system users. Some of the computing devices 104A-D include devices for a database storing the corpus or corpora of data 106 (which is shown as a separate entity in FIG. 1 for illustrative purposes only). Portions of the corpus or corpora of data 106 may also be provided on one or more other network attached storage devices, in one or more databases, or other computing devices not explicitly shown in FIG. 1. The network 102 includes local network connections and remote connections in various embodiments, such that the cognitive system 100 may operate in environments of any size, including local and global, e.g., the Internet.”);
parse, using a natural language processing model, the unstructured EHR data and the metadata to retrieve one or more indicator phrases for the patient, the one or more indicator phrases (Kartoun [0083] “As shown in FIG. 1, the medical condition verification system 120 comprises a medical code/indicator parser 121, one or more natural language processing (NLP) reasoning algorithms 122, one or more cognitive analytics 123, a risk scoring engine 124, a medical condition identification and ranking engine 125, and a GUI engine 126.”, Kartoun [0086] “[0086] The medical code/indicator parser 121 may parse and process the patient EMR data for the patient to identify instances of medical codes or other medical condition indicators, e.g., names of diseases, names of medical conditions, natural language concepts associated with specific diseases or medical conditions, abbreviations representing medical conditions, or the like. From this parsing, a listing of potential medical conditions that the patient may have may be generated, eliminating any duplicates. Each of the medical conditions may then be processed via the one or more NLP reasoning algorithms 122 and/or cognitive analytics 123 to generate supportive evidence for the existence of the medical condition in the patient. The NLP reasoning algorithms 122 may analyze natural language content of the patient EMR data and other information from the various corpora 106, 140, for identifying terms/phrases within the patient EMR data and other corpora 106, 140 that are supportive of, or not supportive of, the medical condition being present in the patient. The cognitive analytics 123 may analyze various medical lab results, demographic classifications of the patient, lifestyle information about the patient, etc. and may apply medical knowledge to such patient information to identify patterns, trends, associations, and the like, that may be supportive of, or not supportive of, the medical condition being present in the patient. The results of these evaluations are considered to be evidential information associated with a medical condition. The evidential information, and source and reasoning associated with this evidential information, may be maintained in association with the medical condition, which in turn is associated with the instances of medical codes/indicators in the EMR data.”, Kartoun [0113] “In the depicted example, the patient EMRs database 322 is a patient information repository that collects patient data from a variety of sources, e.g., hospitals, laboratories, physicians' offices, health insurance companies, pharmacies, etc. The patient EMRs 322 store various information about individual patients, such as patient 302, in a manner (structured, unstructured, or a mix of structured and unstructured formats) that the information may be retrieved and processed by the healthcare cognitive system 300.”, Kartoun [0030] “That is, each instance of a medical code or medical condition indicator may be separately evaluated and an annotation or metadata specifying the instance of the medical code or medical condition indicator and the results of the medical condition verification system operations may be added to the patient EMR to thereby generate a disambiguated patient EMR.”);
input the retrieved one or more indicator phrases and the structured EHR data for the patient into a predictive model (Kartoun [0083] “As shown in FIG. 1, the medical condition verification system 120 comprises a medical code/indicator parser 121, one or more natural language processing (NLP) reasoning algorithms 122, one or more cognitive analytics 123, a risk scoring engine 124, a medical condition identification and ranking engine 125, and a GUI engine 126.”, Kartoun [0086] “The medical code/indicator parser 121 may parse and process the patient EMR data for the patient to identify instances of medical codes or other medical condition indicators, e.g., names of diseases, names of medical conditions, natural language concepts associated with specific diseases or medical conditions, abbreviations representing medical conditions, or the like.”, Kartoun [0113] “In the depicted example, the patient EMRs database 322 is a patient information repository that collects patient data from a variety of sources, e.g., hospitals, laboratories, physicians' offices, health insurance companies, pharmacies, etc. The patient EMRs 322 store various information about individual patients, such as patient 302, in a manner (structured, unstructured, or a mix of structured and unstructured formats) that the information may be retrieved and processed by the healthcare cognitive system 300.”, Kartoun [0030] “That is, each instance of a medical code or medical condition indicator may be separately evaluated and an annotation or metadata specifying the instance of the medical code or medical condition indicator and the results of the medical condition verification system operations may be added to the patient EMR to thereby generate a disambiguated patient EMR.” And Kartoun [0095] “Various structured and unstructured covariates may be learned by the risk scoring engine 124 to be relevant to the evaluation of the presence of a particular medical condition. As noted above, the particular combination of structured and unstructured covariates applicable to a particular medical condition may differ substantially from the combination of covariates used to evaluate other medical conditions. During training, an evaluation of these characteristics with regard to each of the patients in the pool of patients is performed to determine a likelihood that the patient actually has the medical condition indicated or the medical coding or other indicator is likely associated with a related concept rather than the actual medical condition itself. The risk score, or probability value, generated by evaluating these characteristics, or factors, may be compared to a ground truth for the particular patient in the pool of patients, to determine if the medical condition verification system has correctly or incorrectly identified the particular patient as having the particular medical condition.”); and
identify, using the predictive model, the patient as being at risk based on the retrieved indicator phrases and on the structured EHR data (Kartoun [0086] “From this parsing, a listing of potential medical conditions that the patient may have may be generated, eliminating any duplicates. Each of the medical conditions may then be processed via the one or more NLP reasoning algorithms 122 and/or cognitive analytics 123 to generate supportive evidence for the existence of the medical condition in the patient. The NLP reasoning algorithms 122 may analyze natural language content of the patient EMR data and other information from the various corpora 106, 140, for identifying terms/phrases within the patient EMR data and other corpora 106, 140 that are supportive of, or not supportive of, the medical condition being present in the patient.” Kartoun [0087] “The evidential information generated by the NLP reasoning algorithms 122 and/or cognitive analytics 123 may be provided to the risk scoring engine 124 which may generate a risk score, or probability prediction, indicating a probability that the patient has the corresponding medical condition or is at risk of having the corresponding medical condition.” and Kartoun [0113] “In the depicted example, the patient EMRs database 322 is a patient information repository that collects patient data from a variety of sources, e.g., hospitals, laboratories, physicians' offices, health insurance companies, pharmacies, etc. The patient EMRs 322 store various information about individual patients, such as patient 302, in a manner (structured, unstructured, or a mix of structured and unstructured formats) that the information may be retrieved and processed by the healthcare cognitive system 300.”).
Kartoun fails to explicitly teach at least one environmental risk factor and correlated to an Alzheimer's disease (AD) diagnosis.
Spurlock teaches at least one environmental risk factor and correlated to an Alzheimer's disease (AD) diagnosis (Spurlock, page 8, “In any of the embodiments herein, the disease may be a chronic inflammatory disease. The inflammatory disease may be atherosclerosis, stroke, asthma, uveitis, sinusitis, angioedema, psoriasis, psoriatic arthritis, multiple sclerosis, and Alzheimer's disease….Data sets used as training data include outcome data, phenotypic data, environmental data, demographic data, geographic data, genetic data, clinical data, insurance claim data, and treatment data. The models can then be used to identify patients with an increased likelihood of having or developing a disease. The models can be used to differentiate between associations related to early-onset forms of a disease (e.g., juvenile forms) and late-onset forms of a disease (e.g., adult forms). The machine learning system may identify the outcome of a patient as related to the identified disease, well before the risk of disease would be discovered by a patient him- or herself, or in the course of routine doctor visits. The outcome identified by the machine learning algorithm may be diagnosis, comorbidity, severity, prognosis, treatment selection, treatment compliance, reoccurrence, mortality, effectiveness of treatment or quality of life.” Spurlock, page 21-22, “Those assay results are combined into the plurality of data sources 207. Preferably, the plurality of data sources comprises one or more of claims data, demographic data, geographic data, medical history, genetic data, and laboratory test results. In a most preferred embodiment, the data sources include claims data. Insurance claim data may include Healthcare Common Procedures Coding System (HCPCS), Current Procedural Terminology (CPT), or International Classification of Diseases (ICD) Clinical Modifications (CM), National Drug Codes (NDCs), International Classification of Primary Care (ICPC), or International Classification of Functioning, Disability and Health (ICF) codes for example. Insurance claim data may include, for example, individual level patient diagnoses, procedures, prescribed therapies, symptoms, geographic location, demographic information, and/or provider information and can be provided with associated chronological data. Claims data can be provided by medical providers or insurers for analysis. In other embodiments, methods of the invention also use phenotypic data, environmental data, demographic data, geographic data, genetic data, clinical data, treatment data and insurance claim data to determine unique patterns or signatures associated with specific diseases. These data can be derived from a variety of publically available sources, such as PubMed, government databases, for example those databases available on Data.gov. By comparing claims data of healthy patients to claims data of diseased patients or to known outcomes, one can identify patterns in the data that are indicative of certain diseases or disease outcomes. In certain embodiments, the claims data and associated known outcomes may be subjected to machine learning analysis to identify patterns most predictive of disease. In other embodiments, other data sets, such as phenotypic data, environmental data, demographic data, geographic data, genetic data, clinical data and treatment data are also subjected to machine learning analysis to further identify patterns most predicative of disease. All datasets may be subjected to machine learning analysis simultaneously, alternatively, datasets maybe analyzed individually, or in a layered approach to further refine the patterns identified as predictive of disease.”).
It would have been obvious to a person of ordinary skill in the art to apply Kartoun’s known NLP based medical condition verification and risk scoring framework to Alzheimer’s disease (AD) as taught by Spurlock. Both references are directed to predictive modeling of disease risk using patient record data, and substituting AD as the disease of interest represents a predictable use of prior art elements according to their established functions.
With respect to the metadata limitation, Kartoun teaches evaluating structured and unstructured covariates and maintaining metadata associated with identified indicators. Because metadata constitutes structured contextual information routinely stored with EMR data (timestamps, encounter identifiers, classification tags), and because Kartoun analyzes structured covariates in its risk evaluation, it would have been obvious to parse and utilize metadata with unstructured EMR content when identifying indicator phrases. Spurlock teaches the use of environmental risk factor (such as environmental data) and other predictive inputs in AD modeling. Accordingly, it would have been obvious to treat environmental risk factors documented in EMR data as indicator phrases that are indicative of AD risk. Incorporating these known predictive variables into an existing machine learning risk scoring system would have been a routine and predictable choice.
Regarding claim 2, Kartoun and Spurlock teach the invention in claim 1, as discussed above, and further teach wherein the processor is further configured to: generate a prediction for the progression rate of AD based on the retrieved indicator phrases and on the structured EHR data (Kartoun [0083] “As shown in FIG. 1, the medical condition verification system 120 comprises a medical code/indicator parser 121, one or more natural language processing (NLP) reasoning algorithms 122, one or more cognitive analytics 123, a risk scoring engine 124, a medical condition identification and ranking engine 125, and a GUI engine 126.”, Kartoun [0086] “The medical code/indicator parser 121 may parse and process the patient EMR data for the patient to identify instances of medical codes or other medical condition indicators, e.g., names of diseases, names of medical conditions, natural language concepts associated with specific diseases or medical conditions, abbreviations representing medical conditions, or the like.”, Kartoun [0030] “That is, each instance of a medical code or medical condition indicator may be separately evaluated and an annotation or metadata specifying the instance of the medical code or medical condition indicator and the results of the medical condition verification system operations may be added to the patient EMR to thereby generate a disambiguated patient EMR.” and Kartoun [0095] “Various structured and unstructured covariates may be learned by the risk scoring engine 124 to be relevant to the evaluation of the presence of a particular medical condition. As noted above, the particular combination of structured and unstructured covariates applicable to a particular medical condition may differ substantially from the combination of covariates used to evaluate other medical conditions. During training, an evaluation of these characteristics with regard to each of the patients in the pool of patients is performed to determine a likelihood that the patient actually has the medical condition indicated or the medical coding or other indicator is likely associated with a related concept rather than the actual medical condition itself. The risk score, or probability value, generated by evaluating these characteristics, or factors, may be compared to a ground truth for the particular patient in the pool of patients, to determine if the medical condition verification system has correctly or incorrectly identified the particular patient as having the particular medical condition.” and
Spurlock, page 19, Spurlock, FIG. 5 shows a report 501 with a prediction. A report 501 may take any suitable format. For example, in certain embodiments, the report is an electronic document that is both humanreadable and machine-readable, such as a PDF with text-searchable fields or an XML document shared within a system that applies style sheets for display. The report 501 may include information identifying a patient, a disease, and an onset. The onset may be prediction or future time. For example, the report may predict that an individual is at risk for a diagnosis, in 60 months, of amyotrophic lateral sclerosis. In certain embodiments, the methods and systems are operated by a clinical services laboratory that performs an assay on a sample from the patient and also operates the machine learning system to discover associations (e.g., between the assay results and claims data) that are predictive of a future disease state, such as diagnosis, comorbidity, severity, treatment compliance, reoccurrence of disease, or prognosis of disease. In such embodiments, the clinical services laboratory provides the report 501 to a health professional such as the patient's primary care provider.” and Spurlock, page 27, “In various embodiments, methods of the invention provide for diagnosis of diseases such as multiple sclerosis (MS), Parkinson's disease, atherosclerosis, stroke, asthma, uveitis, sinusitis, angioedema, psoriasis, psoriatic arthritis, multiple sclerosis, Alzheimer's disease.”).
Because Kartoun provides a machine learning predictive framework using structured and unstructured patient data, and Spurlock teaches that these machine learning systems may generate time disease outcome and prognosis predictions for Alzheimer’s disease, it would have been obvious to a person of ordinary skill in the art to extend Kartoun’s predictive model to generate a prediction of AD progression rate. This modification represents a predictable use of known machine learning techniques to generate alternative but related predictive outputs (risk, prognosis, progression) using the same input covariates. Therefore, the combination of Kartoun and Spurlock renders the limitation of generating a prediction for the progression rate of AD obvious.
Regarding claim 3, Kartoun and Spurlock teach the invention in claim 2, as discussed above, and further teach wherein the indicator phrases are associated with clinical phenotypes, and wherein to parse the unstructured EHR data for the one or more indicator phrases, the processor is configured to parse the unstructured EHR data using one or more ontologies that associate the indicator phrases with the clinical phenotypes at a contextual level (Kartoun [0024] Various structured and unstructured covariates may be learned to be relevant to the evaluation of the presence of a particular medical condition. Moreover, the particular combination of structured and unstructured covariates applicable to a particular medical condition may differ substantially from the combination of covariates used to evaluate other medical conditions. As an example, structured covariates for insomnia may include certain International Classification of Diseases (ICD) codes (e.g., ICD-9, ICD-10, etc.) or Diagnosis Related Group (DRG) codes for insomnia, a sleep study or additional procedures represented, for instance, by Current Procedural Terminology (CPT) codes, socioeconomic characteristics including age, gender, and ethnicity, particular comorbidities including diabetes, anxiety/depression, renal failure, hypertension, CHF, etc., and medications such as Trazodone, Ambien, and the like. Additional procedures may include a surgery, a blood transfusion, deep brain stimulation, etc. It is noted that our invention is not limited to a specific billing method (such as ICDs and CPTs) and it could be applicable in international healthcare systems that use different billing/clinical documentation methods. Unstructured covariates may include various learned terms or phrases associated with particular medical concepts related to the medical condition, e.g., for insomnia terms/phrases associated with sleep disorder, alcohol use, smoking status, psychiatric disorders, and body mass index (BMI) may be relevant to the evaluation of the actual presence of insomnia in the patient or not. An evaluation of these characteristics with regard to each of the patients in the pool of patients is performed to determine a likelihood that the patient actually has the medical condition indicated or the medical coding or other indicator is likely associated with a related concept rather than the actual medical condition itself.”).
It would have been obvious to a person of ordinary skill in the art at the time of the invention to implement the parsing of unstructured EMR data using known ontology based semantic association techniques, such as hierarchical medical classification systems (ICD or similar vocabularies), to associate extracted indicator phrases with clinical phenotypes at a contextual level. Ontology based parsing was a known technique in clinical natural language processing for improving concept normalization of medical terms. Substituting or incorporating such ontology based concept association into Kartoun’s EMR parsing and medical concept identification framework represents a predictable use of prior art elements according to their established functions to improve standardization of medical condition indicators. Therefore, modifying Kartoun to parse unstructured EHR data using one or more ontologies that associate indicator phrases with clinical phenotypes at a contextual level would have been an obvious choice within the ordinary skill in the art.
Regarding claim 4, Kartoun and Spurlock teach the invention in claim 1, as discussed above, and further teach wherein the predictive model is a machine learning (ML) model (Kartoun [0087] “The evidential information generated by the NLP reasoning algorithms 122 and/or cognitive analytics 123 may be provided to the risk scoring engine 124 which may generate a risk score, or probability prediction, indicating a probability that the patient has the corresponding medical condition or is at risk of having the corresponding medical condition.” and Kartoun [0055] “The cognitive system is a specialized computer system, or set of computer systems, configured with hardware and/or software logic (in combination with hardware logic upon which the software executes) to emulate human cognitive functions. These cognitive systems apply human-like characteristics to conveying and manipulating ideas which, when combined with the inherent strengths of digital computing, can solve problems with high accuracy and resilience on a large scale. A cognitive system performs one or more computer-implemented cognitive operations that approximate a human thought process as well as enable people and machines to interact in a more natural manner so as to extend and magnify human expertise and cognition. A cognitive system comprises artificial intelligence logic, such as natural language processing (NLP) based logic, for example, and machine learning logic, which may be provided as specialized hardware, software executed on hardware, or any combination of specialized hardware and software executed on hardware.”, and Kartoun [0095] “Various structured and unstructured covariates may be learned by the risk scoring engine 124 to be relevant to the evaluation of the presence of a particular medical condition. As noted above, the particular combination of structured and unstructured covariates applicable to a particular medical condition may differ substantially from the combination of covariates used to evaluate other medical conditions. During training, an evaluation of these characteristics with regard to each of the patients in the pool of patients is performed to determine a likelihood that the patient actually has the medical condition indicated or the medical coding or other indicator is likely associated with a related concept rather than the actual medical condition itself. The risk score, or probability value, generated by evaluating these characteristics, or factors, may be compared to a ground truth for the particular patient in the pool of patients, to determine if the medical condition verification system has correctly or incorrectly identified the particular patient as having the particular medical condition.”).
A person of ordinary skill in the art would have understood that generating probability predictions based on learned relationships among structured and unstructured patient characteristics constitutes the use of a machine learning model. To the extent Kartoun’s predictive framework is characterized as a cognitive system performing risk scoring, it would have been obvious to implement such predictive functionality using machine learning techniques because Kartoun teaches ML logic as part of its cognitive system. Employing a machine learning model to generate predictive risk scores represents the predictable use of known ML techniques for disease risk prediction in EMR analytics. Therefore, it would have been obvious to implement the predictive model as a machine learning model.
Regarding claim 5, Kartoun and Spurlock teach the invention in claim 4, as discussed above, and further teach wherein the processor is further configured to build the ML model by using the unstructured EHR data from the database as training data to train the ML model in a first training stage; and using the structured EHR data from the database as training data to train the ML model in a second training stage (Kartoun [0093] “As discussed previously, the risk scoring engine 124 may be trained to learn the appropriate combination of factors and weightings to be applied to these factors when evaluating a patient's probability of having specific medical conditions, where each medical condition may have a separate specific function for combining and weighting the factors to evaluate the risk score or probability of the patient having the medical condition. The training may be based on a pool of training patient EMRs for patients where it is known what medical conditions the patient has, and which patients do not in fact have the medical conditions. Thus, the training of the risk scoring engine 124 may comprise identifying, from a pool of patients, which patients actually have a particular medical condition, e.g., a particular type of cancer, and which do not have the medical condition, even if the patient's EMRs contain indicators that may be interpreted as indicating that the patient has the medical condition. The mechanisms of the illustrative embodiments may have an initial set of factors specified by subject matter experts (SMEs), extracted from natural language processing of electronic documents specifying medical knowledge in the corpus 140, or the like, and may learn the weightings to be applied to these factors. Moreover, in some illustrative embodiments, patients may be correlated into cohorts and their associated characteristics may be compared to identify characteristics shared amongst patients having the same medical condition. Based on such correlations, new combinations of factors may be learned as being indicative of a medical condition for use in verifying the medical code/indicator.” and Kartoun [0113] “In the depicted example, the patient EMRs database 322 is a patient information repository that collects patient data from a variety of sources, e.g., hospitals, laboratories, physicians' offices, health insurance companies, pharmacies, etc. The patient EMRs 322 store various information about individual patients, such as patient 302, in a manner (structured, unstructured, or a mix of structured and unstructured formats) that the information may be retrieved and processed by the healthcare cognitive system 300.”).
It would have been obvious to a person of ordinary skill in the art to implement the model training in multiple stages, such as first training on features derived from unstructured EHR data (NLP-extracted terms) and subsequently refining or further training the model using structured EHR data. Sequential or staged training of machine learning models, including partitioning training inputs by feature type, was a known and predictable design variation used to improve training efficiency. Implementing this staged training using known data categories (structured versus unstructured EMR data) is considered a predictable variation of Kartoun’s disclosed ML training framework using known training data sources. Therefore, configuring the processor to train the ML model in a first stage using unstructured EHR data and in a second stage using structured EHR data would have been an obvious implementation choice within the ordinary skill in the art.
Regarding claim 6, Kartoun and Spurlock teach the invention in claim 1, as discussed above, and further teach wherein the processor is further configured to: store, in the database, a list of indicator phrases, wherein identifying the patient as being at risk for AD includes comparing the parsed indicator phrases against the list of indicator phrases (Kartoun [0024] “Various structured and unstructured covariates may be learned to be relevant to the evaluation of the presence of a particular medical condition. Moreover, the particular combination of structured and unstructured covariates applicable to a particular medical condition may differ substantially from the combination of covariates used to evaluate other medical conditions. As an example, structured covariates for insomnia may include certain International Classification of Diseases (ICD) codes (e.g., ICD-9, ICD-10, etc.) or Diagnosis Related Group (DRG) codes for insomnia, a sleep study or additional procedures represented, for instance, by Current Procedural Terminology (CPT) codes, socioeconomic characteristics including age, gender, and ethnicity, particular comorbidities including diabetes, anxiety/depression, renal failure, hypertension, CHF, etc., and medications such as Trazodone, Ambien, and the like. Additional procedures may include a surgery, a blood transfusion, deep brain stimulation, etc. It is noted that our invention is not limited to a specific billing method (such as ICDs and CPTs) and it could be applicable in international healthcare systems that use different billing/clinical documentation methods. Unstructured covariates may include various learned terms or phrases associated with particular medical concepts related to the medical condition, e.g., for insomnia terms/phrases associated with sleep disorder, alcohol use, smoking status, psychiatric disorders, and body mass index (BMI) may be relevant to the evaluation of the actual presence of insomnia in the patient or not. An evaluation of these characteristics with regard to each of the patients in the pool of patients is performed to determine a likelihood that the patient actually has the medical condition indicated or the medical coding or other indicator is likely associated with a related concept rather than the actual medical condition itself.”, Kartoun [0086] “The medical code/indicator parser 121 may parse and process the patient EMR data for the patient to identify instances of medical codes or other medical condition indicators, e.g., names of diseases, names of medical conditions, natural language concepts associated with specific diseases or medical conditions, abbreviations representing medical conditions, or the like. From this parsing, a listing of potential medical conditions that the patient may have may be generated, eliminating any duplicates. Each of the medical conditions may then be processed via the one or more NLP reasoning algorithms 122 and/or cognitive analytics 123 to generate supportive evidence for the existence of the medical condition in the patient. The NLP reasoning algorithms 122 may analyze natural language content of the patient EMR data and other information from the various corpora 106, 140, for identifying terms/phrases within the patient EMR data and other corpora 106, 140 that are supportive of, or not supportive of, the medical condition being present in the patient. The cognitive analytics 123 may analyze various medical lab results, demographic classifications of the patient, lifestyle information about the patient, etc. and may apply medical knowledge to such patient information to identify patterns, trends, associations, and the like, that may be supportive of, or not supportive of, the medical condition being present in the patient. The results of these evaluations are considered to be evidential information associated with a medical condition. The evidential information, and source and reasoning associated with this evidential information, may be maintained in association with the medical condition, which in turn is associated with the instances of medical codes/indicators in the EMR data.” Kartoun [0030] “During runtime operation, after the training of the medical condition verification system has been completed, the medical condition verification system may evaluate medical condition indicators, e.g., medical codes or other medical condition indicators, in a patient EMR of an actual patient being treated by a physician or other medical personnel, either prior, after, or commensurate with an encounter with the patient. Based on the results of the evaluation, the medical condition verification system may add annotations to the patient EMR to indicate whether the particular medical codes or other medical condition indicators (assumed hereafter to be medical codes for purposes of ease of explanation) are in fact valid indicators of the medical condition or are associated with a related concept to the medical condition and not in fact indicative of the medical condition itself being present in the patient. That is, each instance of a medical code or medical condition indicator may be separately evaluated and an annotation or metadata specifying the instance of the medical code or medical condition indicator and the results of the medical condition verification system operations may be added to the patient EMR to thereby generate a disambiguated patient EMR.” and Kartoun [0093]” As discussed previously, the risk scoring engine 124 may be trained to learn the appropriate combination of factors and weightings to be applied to these factors when evaluating a patient's probability of having specific medical conditions, where each medical condition may have a separate specific function for combining and weighting the factors to evaluate the risk score or probability of the patient having the medical condition. The training may be based on a pool of training patient EMRs for patients where it is known what medical conditions the patient has, and which patients do not in fact have the medical conditions. Thus, the training of the risk scoring engine 124 may comprise identifying, from a pool of patients, which patients actually have a particular medical condition, e.g., a particular type of cancer, and which do not have the medical condition, even if the patient's EMRs contain indicators that may be interpreted as indicating that the patient has the medical condition. The mechanisms of the illustrative embodiments may have an initial set of factors specified by subject matter experts (SMEs), extracted from natural language processing of electronic documents specifying medical knowledge in the corpus 140, or the like, and may learn the weightings to be applied to these factors. Moreover, in some illustrative embodiments, patients may be correlated into cohorts and their associated characteristics may be compared to identify characteristics shared amongst patients having the same medical condition. Based on such correlations, new combinations of factors may be learned as being indicative of a medical condition for use in verifying the medical code/indicator.” and
Spurlock, page 8, “In any of the embodiments herein, the disease may be a chronic inflammatory disease. The inflammatory disease may be atherosclerosis, stroke, asthma, uveitis, sinusitis, angioedema, psoriasis, psoriatic arthritis, multiple sclerosis, and Alzheimer's disease. The disease may be an autoimmune disease such as fibromyalgia, rheumatoid arthritis, lupus, ankylosing spondylitis, Hashimoto's thyroiditis, Sjogren's syndrome, Graves' disease, inflammatory bowel disease, Crohn's disease, ulcerative colitis, celiac disease, pernicious anemia, and sinusitis. In other embodiments, the disease may be more than one disease occurring at the same time resulting in comorbidity. In yet another embodiment, onset of the comorbidity of diseases may occur at a point in time after the first diagnosis of a disease. Preferably, the machine learning algorithm is implemented in a computing system comprising at least one processor coupled to a tangible, non-transitory memory subsystem. In certain embodiments, the machine learning algorithm includes a neural network. Methods of the invention may further be used for determining disease outcome of a patient includes stratifying the data to identify shared commonalties amongst the data. The shared commonalties are used to generate a disease specific network. In other embodiments, the disease networks may be used to construct data sets which can be used to train models. In some embodiments, the machine learning algorithm identifies patterns within training data sets. Data sets used as training data include outcome data, phenotypic data, environmental data, demographic data, geographic data, genetic data, clinical data, insurance claim data, and treatment data. The models can then be used to identify patients with an increased likelihood of having or developing a disease. The models can be used to differentiate between associations related to early-onset forms of a disease (e.g., juvenile forms) and late-onset forms of a disease (e.g., adult forms). The machine learning system may identify the outcome of a patient as related to the identified disease, well before the risk of disease would be discovered by a patient him- or herself, or in the course of routine doctor visits. The outcome identified by the machine learning algorithm may be diagnosis, comorbidity, severity, prognosis, treatment selection, treatment compliance, reoccurrence, mortality, effectiveness of treatment or quality of life.”).
It would have been obvious to a PHOSITA to implement Kartoun’s learned unstructured covariates as a stored list of indicator phrases and to compare parsed phrases against that list in order to efficiently determine whether relevant indicators are present in a patient’s EMR. Spurlock is relied upon for teaching application of machine learning systems to Alzheimer’s disease prediction, thereby providing motivation to apply Kartoun’s EMR based phrase identification and risk evaluation framework to AD risk determination. Accordingly, the claimed limitation would have been obvious.
Regarding claim 7, Kartoun and Spurlock teach the invention in claim 1, as discussed above, and further teach wherein the unstructured EHR data includes clinical notes, wherein the clinical notes include information relating to one or more of cognitive concerns, changes in behavior, personal or family medical history, or ability to perform daily activities (Kartoun [0025] “During a training phase of development of the medical condition verification system of the illustrative embodiments, the medical condition verification system may evaluate patient EMRs to determine, for each medical condition for which the mechanisms are being trained, a risk score, e.g., an instance probability, for the medical condition, e.g., disease, based on an evaluation of the structured and unstructured covariates established for the particular medical condition. A formula may be implemented to calculate the risk score for the medical condition, e.g., disease, where the formula comprises one or more characteristics, such as comorbidities, medications, laboratory measurements, and mentions in clinical narrative notes. A combination of structured and unstructured covariates may be used to calculate the risk score of the patient using such a function.” Kartoun [0026] For example, for an insomnia medical condition, the probability of insomnia, and thus the risk score for insomnia, may be calculated using the following formula in one illustrative embodiment, considering patient's history (either restricted by a time range, e.g., 12 months, or unrestricted): I=X+a*[#Insomnia]+b*[#Anxiety and Depression]+c*[#Joint Disorder]+d*[#EMR Facts]+e*[# Sleep Medications]+P[#Sleep Disorder]+g*[#Psychiatric Disorder](1) P(Insomnia)=exp(I)/(1+exp(I))(2) where, in equation (1) above, X is a constant, “a” through “g” are coefficients whose values are learned through machine learning and training of the medical condition verification system, and the factors in brackets indicate a number of instances of factors corresponding to the particular factor type, e.g., number of occurrences of the medical code for insomnia in the patient's EMR, number of instances of mentions of anxiety and depression concepts in the patient EMR, number of instances of mentions of joint disorder in the patient EMR, number of sleep medications the patient is on, number of sleep disorders mentioned in the patient's EMR, number of psychiatric disorders mentioned in the EMR, etc. that are associated with insomnia. That is, for each of these types of factors, for the particular medical condition, certain medical codes, indicators, non-negated terms/phrases extracted from clinical narrative notes corresponding to particular ones of these types of factors that are relevant to the presence, or non-presences, of the medical condition (insomnia) may be provided and in determining the risk score for the medical condition, those particular factors are used to generate the values for entry into the [# . . . ] elements of equation (1) above. Thereafter, the probability P of the medical condition is calculated using equation (2) to thereby generate the risk score for the medical condition being present in the patient.”).
Accordingly, it would have been obvious to a person of ordinary skill in the art to utilize unstructured clinical narrative notes containing mentions of insomnia or related psychiatric conditions as behavioral indicators when evaluating a patient’s risk of a medical condition. Kartoun teaches extracting and analyzing terms and phrases from clinical narrative notes to determine disease presence and risk. Applying that same known technique to a specific disease context such as Alzheimer’s disease represents no more than the predictable use of prior art elements according to their established functions. Therefore, the claimed limitation that the unstructured EHR data includes clinical notes containing information relating to changes in behavior is taught or at least suggested by Kartoun.
Regarding claim 8, Kartoun and Spurlock teach the invention in claim 1, as discussed above, and further teach wherein the processor is further configured to: link, based on the metadata, the indicator phrases to the structured EHR data (Kartoun [0030] “Based on the results of the evaluation, the medical condition verification system may add annotations to the patient EMR to indicate whether the particular medical codes or other medical condition indicators (assumed hereafter to be medical codes for purposes of ease of explanation) are in fact valid indicators of the medical condition or are associated with a related concept to the medical condition and not in fact indicative of the medical condition itself being present in the patient. That is, each instance of a medical code or medical condition indicator may be separately evaluated and an annotation or metadata specifying the instance of the medical code or medical condition indicator and the results of the medical condition verification system operations may be added to the patient EMR to thereby generate a disambiguated patient EMR.”, Kartoun [0021] “For example, from a large set of patient EMRs, a pool of patients may be generated that have indicators, e.g., medical codes, indicative of a particular medical condition, e.g., particular type of cancer patients, type 2 diabetes patients, insomnia patients, etc. The mechanisms of the illustrative embodiments learn, from natural language processing of guidelines documents, medical publications, information provided by subject matter experts (SMEs), e.g., clinician expertise, and the like, the patient characteristics that are supportive and/or not supportive of the hypothesis that the patient has the medical condition indicated by the medical code or other indicator of the medical condition. For example, through an ingestion of such electronic documents, various factors may be identified that are relevant to a particular medical condition, e.g., particular medical codes, patient demographics, comorbidities, medications, related medical concepts, and natural language terms/phrases associated with the medical condition or related medical concepts may be learned through a natural language processing and ingestion of the medical knowledge from these electronic documents.”).
It would have been obvious to a person of ordinary skill in the art to link extracted indicator phrases from unstructured EHR data to structured EHR data using metadata, as taught by Kartoun, in order to maintain data integrity and enable consistent downstream risk evaluation. Utilizing metadata to associate extracted narrative indicators with structured patient records represents the predictable use of known data management and annotation techniques to improve medical condition verification systems. Applying metadata based linking between unstructured indicators and structured EHR data is no more than the predictable implementation of established EMR annotation practices to achieve reliable and organized condition analysis.
Claims 9-16 are analogous to claims 1-8, thus claims 9-16 are similarly analyzed and rejected in a manner consistent with the rejection of claims 1-8.
Claims 17-19 are analogous to claims 1-3, thus claims 17-19 are similarly analyzed and rejected in a manner consistent with the rejection of claims 1-3.
Claim 20 is analogous to claims 4-5, thus claim 20 is similarly analyzed and rejected in a manner consistent with the rejection of claims 4-5.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted on 12/15/2025 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. The rejection of claims 1-20 under 35 U.S.C. § 101 is maintained.
With respect to Step 2A, Prong One, the claims recite an abstract idea including mental processes. The claimed steps of parsing electronic health record data to identify indicator phrases correlated with Alzheimer’s disease and identifying a patient as being at risk constitute analysis and evaluation of information, which fall within the mental process grouping. Applicant states that retrieving and parsing data stored in predefined data structures cannot practically be performed in the human mind, and this is not persuasive. As claimed, these steps automate what clinicians can do manually (reviewing records, identifying disease indicators, and assessing risk), and the use of a computer or database does not remove the claim from the mental process category. Applicant’s statements regarding the August 4, 2025 USPTO memorandum are not persuasive. The claims do not recite limitations that fundamentally cannot be performed by the human mind; instead, they recite generic computer implementation of analyzing clinical information to reach a diagnostic risk determination. Accordingly, the claims recite a judicial exception.
With respect to Step 2A, Prong Two, the claims do not integrate the abstract idea into a practical application. The additional elements (a processor, natural language processing model, and predictive model) are recited at a high level of generality and function as tools to perform the abstract idea. The claims do not recite any specific improvement to computer technology, natural language processing, data structures, or predictive modeling techniques. Applicant’s arguments regarding technical problems and technical effects rely on descriptions in the specification; however, the claims themselves do not recite the particular technical means by which any such improvement is achieved. Improving the accuracy of a medical prediction or applying data analysis to a healthcare context is not a technological improvement.
Lastly, Applicant’s arguments under Step 2B are not persuasive. Applicant discusses unique data structures and other features that are not recited in the claims. Eligibility under §101 must be based on the claim language, not features discussed in the specification. As claimed, the additional elements amount to no more than generic computer implementation, and data retrieval/data input steps, and the latter are well-understood, routine, and conventional in the field of data analytics and machine learning.
Claims 1-20 remain directed to an abstract idea without reciting additional elements sufficient to amount to significantly more, and the rejection under 35 U.S.C. § 101 is therefore maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments have been fully considered but are not persuasive. Applicant states that neither Kartoun nor Spurlock teaches “parsing, using a natural language processing model, the unstructured EHR data and the metadata to retrieve one or more indicator phrases… including at least one environmental risk factor and correlated to Alzheimer’s disease (AD).” This is not consistent with the combined teachings of the references. Kartoun teaches parsing patient EMRs, including unstructured clinical narrative content, using natural language processing to identify medical condition indicators and natural language terms and phrases associated with specific medical conditions. Kartoun further teaches associating these indicators with structured covariates and adding annotations or metadata specifying instances of medical codes or indicators within the EMR to generate a disambiguated record. The use of metadata to associate indicators with EMR content shows linking and contextual association of extracted phrases within the patient record. Kartoun also teaches that environmental data may be used as part of the training data. Spurlock teaches that environmental data may be used as part of the training data, as well as applying machine learning models to disease prediction, including Alzheimer’s disease. When Kartoun’s NLP based extraction of medical indicators from unstructured EMR data is combined with Spurlock’s predictive disease modeling, it would have been obvious to a person of ordinary skill in the art to include environmental risk factors as indicator phrases extracted from EMR content for AD risk prediction.
Applicant’s argument that Spurlock is “silent as to using metadata” is not persuasive because the rejection does not rely on Spurlock for metadata parsing. Kartoun teaches annotating EMR entries with metadata specifying indicator instances and evaluation results. Linking extracted indicator phrases to structured EMR data via metadata represents a predictable implementation of known EMR annotation and data association techniques. Applying known NLP extraction techniques to retrieve environmental risk factor phrases for AD prediction is no more than the predictable use of prior art elements according to their established functions.
With respect to dependent claims 2-8, 10-16, and 18-20, Applicant has not presented arguments directed to specific additional limitations beyond those addressed for the independent claims. The cited references, individually and in combination, teach or suggest the additional limitations for the reasons set forth in the Office Action. Therefore, the rejection of claims 1-20 under 35 U.S.C. §103 is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure.
Crafts et al. (U.S. Publication 2017/0124263) teaches scalable clinical, genomic, and patient health records data, analyzes data in response to queries through condition specific workflows, and dynamically presents role and workflow based visualizations using predefined templates.
Kukreja et al. (U.S. Publication 2021/0334462 A1) teaches a system and method that parses unstructured text and detects negation, and also integrates patient data, computes disease and risk scores, and flags patients for intervention.
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
/SCOTT D GARTLAND/
Primary Examiner, Art Unit 3685