DETAILED ACTION
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 the Claims
The office action is in response to the claim amendments and remarks filed on October 23, 2025 for the application filed April 27, 2022 which claims priority to a provisional application filed on July 25, 2014. Claims 1 and 14 have been amended and claims 5-8 have been cancelled. Claims 1-4 and 9-15 are currently pending and have been examined.
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-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-15 are directed towards a system for making quality measure submissions and providing multiple measure review of patient care (i.e. a machine) which is a statutory category. Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e. a law of nature, a natural phenomenon, or an abstract idea). In the instant application, the claims are directed towards an abstract idea.
Under 2A, prong one of the 2019 Revised Patent Subject Matter Eligibility Guidance, independent claims 1 and 14 are determined to be directed to an abstract idea because an abstract idea is recited in the claims which fall within the subject matter groupings of abstract ideas. The abstract idea recited in claims 1 and 14 is identified in representative claim 1 in bold as:
a data input system configured to collect patient input from a user/a provider input device for inputting patient data, wherein the provider input patient data comprises patient age and patient insurance, wherein the user associates a fact with the specific object, using the data input system, and the system assigns a structured descriptive data item to the fact associated with the specific object;
a data output system configured to generate a report, wherein a quality measure is displayed in real time using the data output system as the patient data is entered, wherein the quality measure is calculated in real time;
a database comprising structured descriptive data items, wherein the descriptive data items comprise examination findings, diagnosis, and treatment data records, wherein data in the database is associated with a particular object, wherein the object comprises a patient and a body part,
a processor in communication with the data input system, the data output system and the database, wherein the processor is configured to tag a specific object input by the user with one or more of the structured descriptive data items;
wherein the processor is configured to determine if the patient is eligible for a quality measure calculation, wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance;
wherein the processor is configured to determine whether the structured descriptive data item assigned to the fact should be assigned as metadata;
a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree; and
a rules engine, executing on the processor, the rules engine in communication with the patient database, the rules engine configured to/for traversing a hierarchical tree of denominator and numerator questions/rules, using provider patient input and patient data items from the database to generate, from multiple encounter and multiple measures, the review of patient care and quality measure submissions subsequent to each patient visit, wherein the review of patient care comprises the one or more quality measures, wherein the report comprises a summary breakdown by quality measure of the Current Procedural Terminology codes and the percentage of quality measures transmitted using the one or more quality measures, wherein each quality measure in the report is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure;
wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules.
The identified limitations in the identified abstract idea fall within the subject matter grouping of mental processes. The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting “a data input system configured to”, “a processor configured to” “the rules engine configured to/for”, “automatically”, “the logic block configured to” and “a data output system configured to”, nothing in the identified limitations precludes the steps from practically being performed in the mind or on pen and paper. For example, collecting data, associating data, assigning data, tagging data, making determinations on eligibility and quality measures, traversing a hierarchical tree of denominator and numerator rules, examining facts, make determinations on meeting requirements, generating reports in real-time by calculating quality measures in rea-time as data is acquired and determining what to data display in the report and whether to override calculation quality measures using observation, judgements, evaluations and opinions. If claim limitations, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. The mere nominal recitation of a data input system, a data output system, a database, a processor and a rules engine do not take the claim out of the mental process grouping. Thus, the claim recites an abstract idea.
Under step 2A, prong two of the 2019 Revised Patent Subject Matter Eligibility Guidance, it must be determined whether the identified abstract ideas are integrated into a practical application. After evaluation, there is no indication that any additional elements or combination of elements integrate the abstract idea into a practical application, such as through: an additional element that reflects an improvement to the functioning of a computer, or an improvements to any other technology or technical field; an additional element that applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition; an additional element that implements the judicial exception with, or uses the judicial exception in connection with, a particular machine or manufacture that is integral to the claim; an additional element that effects a transformation or reduction of a particular article to a different state or thing; or an additional element that applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Conversely, the additional elements, other than the abstract idea per se, when considered both individually and as an ordered combination, amount to no more than a recitation of:
Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea under MPEP §2106.05(f). The additional elements of: a data input system configured to collect patient input; a provider input device for inputting patient data; a data output system configured to; a database comprising descriptive data items; a processor in communication with the data input system, the data output system and the database; automatically; a logic block executing on the processor, the logic block configured to automatically; a rules engine, executing on the processor, the rules engine in communication with the patient database, the rules engine configured to/for; and a link for displaying data are considered to be similar to adding the words “apply it” with the judicial exception, mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea because the claims recite only the idea of a solution or outcome and fail to recite details of how a solution to a problem is accomplished (how questions and rules are traversed, what the data items are, what the patient input data is and how a review is generated). The claimed computer components are recited at a high level of generality, used in their ordinary capacity and are merely invoked as tools to perform a review of patient care, the quality measure submission process and the report generation. Simply implementing the abstract idea on a generic computer to automate an manual process cannot be considered a practical application of the abstract idea.
Generally linking the use of a judicial exception to a particular technological environment or field of use under MPEP §2106.05(h). The limitations specifying that the quality measures in the report are a link which displays additional information and options generally links the abstract idea of generating reports with quality measures and determining if calculation of quality measures should be overridden the computer environment and specifically to link based display of information (i.e. hyperlinks) as opposed to other ways to display or associate information.
Under step 2B of the 2019 Revised Patent Subject Matter Eligibility Guidance, it must be determined whether provide an inventive concept by determining if the claims include additional elements or a combination of elements that are sufficient to amount to significantly more than the judicial exception. After evaluation, there is no indication that an additional element or combination of elements are sufficient to amount to significantly more than the judicial exception. As discusses above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components or merely utilizing generic computer components as a tool to perform the judicial exception. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Thus the claims are not patent eligible.
The dependent claims merely present additional abstract information in tandem with further details regarding the elements from the independent claims and are, therefore, directed to an abstract idea for similar reasons as given above. Dependent claims 2-3 merely indicate what the descriptive data items are. Dependent claims 9-11 merely indicate how the rules are applied at a fairly high level and in an abstract fashion. For example, simply liking descriptive items is a relational database, assigning facts and metadata to descriptive items transforming unstructured data into structured data, assigning objects to descriptive items is appending information to information and providing outcome values of the rules is the inherent result of computer based rules and an abstract mental process implemented on a computer. Dependent claim 12-13 and 15 merely indicates that results of the rules may be output to users or provided to other systems. None of these functions are deemed to integrate the claims into a practical application or to amount to significantly more than the abstract idea because, as stated above, they amount to: adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer. These merely encompasses the abstract idea identified above and do not amount to significantly more.
Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements amounts to an inventive concept.
Therefore, whether taken individually or as an ordered combination, claims 1-4 and 9-15 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4 and 9-15 are rejected under 35 U.S.C. 103 as being unpatentable over Spitznagel et al. (U.S. Pub. No. 2015/0356646) in view of Stanley et al. (U.S. Patent No. 8,311,854) and Sublett et al. (U.S. Pub. No. 2015/0112700).
Regarding claim 1, Spitznagel discloses an automated system for making Abstract and paragraphs [0021]-[0022], [0030] and [0140]-[0141] discus a system for making automatically derive billing codes from a patient encounter to automatically assembly and submit reports for billing.), the system comprising:
a data input system configured to collect patient input (Paragraphs [0031] and [0037] discuss the system including a data input system, such as a keyboard and associated user interface/word processing system, for inputting patient data.), wherein the user associates a fact with a specific object, using the data input system, and the system assigns a structured descriptive data item to the fact associated with the specific object (Figs. 2-4 and paragraphs [0030]-[0032] and [0087]-[0097] show and discuss that the user associates unstructured facts with a object through free-form data entry and that the system assigns a structured medical facts to the unstructured fact associated with the object. For example, a “chest pain” object is associated with the unstructured fact “patient is presenting chest pain” and the system assigns the structured fact “unspecified chest pain” to the unstructured fact “patient is presenting chest pain”.);
a data output system Paragraphs [0140]-[0141] discuss that the system includes a user interface screen for displaying/outputting information to a user and that the system may send information to other processes, construed as a data output system.);
a database comprising structured descriptive data items (Paragraphs [0026], [0030], [0105] and [0142] discuss that the system includes a database for storing structured medical facts related to a patient, construed as structured descriptive data items.) wherein the structured descriptive data items comprise examination findings, diagnosis, and treatment data records, wherein data in the database is associated with a particular object, wherein the object comprises a patient and a body part (Paragraph [0032], Such facts currently required by the Meaningful Use standards include social history facts, allergy facts, diagnostic test result facts, medication facts, problem facts, procedure facts, and vital sign facts. Other non-limiting examples of suitable categories of medical facts include findings, disorders, body sites, medical devices, subdivided categories such as observable findings and measurable findings, etc.);
a processor in communication with the data input system, the data output system and the database (Fig. 1 and paragraphs [0033] and [0142] show and discuss a computer having a processor in communication with the user interface, input devices and a database.) wherein the processor is configured to tag a specific object input by the user with one or more of the structured descriptive data items (Figs. 2-4 and paragraphs [0030]-[0032] and [0086]-[0097] show and discuss that the system provides indicators, construed as tags, which provide a linkage between an unstructured object input by a user, such as “chest pain” and a structured medical facts, such as “unspecified chest pain” as shown in fig. 3A.);
wherein the processor is configured to determine whether the structured descriptive data item assigned to the fact should be assigned as metadata (Figs. 2-4 and paragraphs [0030]-[0032], [0068]-[0071] and [0087]-[0095] show and discuss that the system determines whether an structured medical fact assigned to the unstructured medical fact should be assigned a label or field, construed as metadata.);
a rules engine, executed on the processor, the rules engine configured to traverse a hierarchical tree Paragraphs [0021]-[0022], [0078]-[0079], [0105], [0108] and [0119]-[0120] discuss that the processor may include natural language understand (NLU) engine which includes rules for automatically traversing a hierarchical tree of medical codes based on inputted patient data and data from the database of stored structured medical facts. Also see fig. 1.),
Spitznagel further discloses that the medical billing codes for submitting reports for billing may include codes mandated by the Centers for Medicare and Medicaid Services (Paragraphs [0005]-[0006]), but does not appear to explicitly disclose that the automated system is for making quality measure submissions; the data output system configured to generate a report; wherein the processor is configured to determine if the patient is eligible for a quality measure calculation, wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance; a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree; that the rules engine is configured to traverse a hierarchical tree of denominator and numerator questions; wherein the report comprises a summary breakdown of quality measures of Current Procedural Terminology codes and a percentage of quality measures transmitted; or wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules.
However, Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing to provide an automated system for making quality measure submissions (Column 1, lines 13-18, column 2, lines 16-34, column 3, lines 39-65, column 6, lines 35-38 and column 14, lines 44-63 discuss an automated system for submitting quality measure reports to comply with the Physician Quality Reporting Initiatives.), the system comprising:
a processor, wherein the processor is configured to determine if the patient is eligible for a quality measure calculation, wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance (Column 5, lines 19-63 discuss the practice management module automatically selects patient data records for the quality measurement evaluation based on matching information in the patient data records with information for the quality measure, such as age, sex and insurance.); and
a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree (Figs. 6A-6C shows the logical routine for the quality measure/specified data records selection (i.e. patient eligibility) and the algorithms/rules for the denominator determination and numerator determination used to automatically determine quality measures and that the rules are in a hierarchical tree format. Also see column 4, lines 28-38, column 7, lines 7-36, column 8, lines 1-37, column 11, lines 36-65, column 12, lines 36-67 and column 13, lines 1-12 and Tables I-III.); and
a rules engine constructed to traverse a hierarchical tree of denominator and numerator questions (Column 4, lines 28-38, column 7, lines 7-36, column 8, lines 1-37 and column 13, lines 6-12 discuss an automated computer system having logical routines which used rules to traverse hierarchical tree of denominator questions and numerator questions using patient demographic data. For example, the system uses rules and patient data to first traverse denominator questions to determine if the patient meets the denominator reporting requirements and then traverse numerator questions to determine if the patient meets the numerator reporting requirements. As shown in figs. 6A-6C and Tables I-III, these questions/rules are in a hierarchical tree format.);
to define quality measures by Current Procedural Terminology codes (Figs. 3, 4C and tables 1 and 2 shows what CPT codes are required for different quality measures denominator/numerator criteria.), and
wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules (Column 4, lines 28-38 and 66-67, column 5, lines 1-17, column 7, lines 7-36, column 8, lines 1-37 and column 13, lines 6-12 discuss an automated computer system having logical routines which used rules to traverse hierarchical tree of denominator questions and numerator questions using patient structured demographic data to determine if the demographic data meets the requirements of the rules. Structured demographic data is construed as medical facts having associated metadata. As shown in figs. 6A-6C and Tables I-III, these rules are in a hierarchical tree format.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the filing to modify the system of Spitznagel: such that the system is for making quality measure submissions; wherein the processor is configured to determine if the patient is eligible for a quality measure calculation, wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance; to include a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree; such that hat the rules engine is configured to traverse a hierarchical tree of denominator and numerator question; and wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Spitznagel as modified by Stanley does not appear to explicitly disclose that the data output system is configured to generate a report comprising a summary breakdown of quality measures of Current Procedural Terminology codes and a percentage of quality measures transmitted using the determined one or more quality measures; or wherein each quality measure in the report is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure.
Sublett teaches that it was old and well known in the art healthcare quality measures at the time of the filing to provide a data output system configured to generate a report, wherein the report comprises a summary breakdown by quality measures of numerator and denominator criteria and percentage of quality measures transmitted using determined one or more quality measures (Fig. 13 and paragraph [0112]-[0114] shows and discusses generated reports which include a breakdown different quality measures to include the percentage of patients who met a quality measure and the numerator and denominator information. Fig. 14 and paragraph [0118] shows and discusses generated reports which include a breakdown of different quality measures to include completion percentage of quality and the numerator and denominator information. Also see fig. 10 and paragraph [0104] which discuss transmitting the reports.); and
wherein each quality measure in the report is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure (Paragraph [0115], selection of an item on the interface 1300 provides further information regarding that item to the user. Paragraph [0120], for a particular measure 1501, additional detail is displayed to the user such as a stratum for the measure (patients age 3-11 in this example), an explanation of the numerator (patients who had a height, weight and body mass index percentile recorded during the measurement period in this example). Paragraph [0121], via the interface(s) 1300, 1400, 1500 a user can see which measures the user passed or failed and can drill in to see what is happening with each particular measure and/or group of measures. Paragraph [0122], an interface for a user to select a set of measures/requirements (e.g., MU, PQRS, etc.) and then select which measures he or she is going to track. Only those selected measures appear in the dashboard for that provider, for example. Also see paragraph [0123] and figs. 13-15.) to help improve departmental operations and streamline reimbursement documentation, support, and processing (Paragraph [0045]).
Therefore, it would have been obvious to one of ordinary skill in the art of healthcare quality measures at the time of the filing to modify the system of Spitznagel such that the data output system is configured to generate a report, wherein the report comprises a summary breakdown by quality measures and percentage of quality measures transmitted using the determined one or more quality measures; and wherein each quality measure in the report is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure, as taught by Sublett, and such that the numerator and denominator criteria includes the CPT codes, as taught by Stanley, in order to help improve departmental operations and streamline reimbursement documentation, support, and processing.
Regarding claim 2, Spitznagel further discloses wherein structured descriptive data items comprise Systemized Nomenclature of MEDicine (SNOMED), International Classification of Diseases, Ninth Revision (ICD9), International Classification of Diseases, Tenth Edition (ICD10), RxNorm, Local Observation Identifier for Names and Codes (LOINC), Current Procedural Terminology (CPT) and Metathesaurus code value pairs (Paragraphs [0005], [0076]-[0077] and [0087]-[0095] discuss that the utilizes or contemplates utilizing SNOMED, ICD9, ICD10, RxNorm, LOINC, CPT and UMLS, construed as Metathesaurus code value pairs, for data items related to the medical facts.)
Regarding claim 3, Spitznagel further discloses wherein structured descriptive data items comprise descriptive string and at least one of a code system and a specific code value (Paragraphs [0087]-[0095] discuss that the medical facts may include structure fields which include a descriptive textual string of the medical fact, an associated code system for describing the medical fact and a specific code identifying the medical fact within the code system.).
Regarding claim 4, Spitznagel further discloses wherein structured descriptive data items are linkable to other descriptive data items (Paragraphs [0045]-[0046] discus that the medical facts may be linked together to form relationships between the medical facts.).
Regarding claim 9, Spitznagel does not appear to explicitly disclose, but Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing wherein the rules engine uses the metadata assigned to the facts to determine an outcome value of a specific rule (Column 4, lines 39-65, column 7, lines 7-36 and column 8, lines 1-37 discuss that the system uses the structured patient demographic data to determine an outcome value, such as required quality measure code and the presence thereof, based on a rule specific to a quality measure. Also see figs. 6A-6C and Tables I-III.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the filing to modify the system of Spitznagel to such that the rules engine uses the metadata assigned to the facts to determine an outcome value of a specific rule, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Regarding claim 10, Spitznagel does not appear to explicitly disclose, but Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing wherein the rules engine associates the outcome with the specific object to which the fact apply (Column 4, lines 39-65, column 7, lines 7-36 and column 8, lines 1-37 discuss that the system associates an outcome of a rule with a specific patient record for which the demographic data applies. Also see figs. 6A-6C and Tables I-III.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the filing to modify the system of Spitznagel to such that the rules engine associates the outcome with the object value to which the fact applies, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Regarding claim 11, Spitznagel does not appear to explicitly disclose, but Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing wherein the rules engine determines an outcome value of a specific rule in response to an outcome value generated by other rules (Column 4, lines 39-65, column 7, lines 7-36 and column 8, lines 1-37 discuss that the system determines a numerator rule outcome value in response to the denominator rule outcome value. Also see figs. 6A-6C and Tables I-III.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the filing to modify the system of Spitznagel to such that the rules engine determines an outcome value of a specific rule in response to an outcome value generated by other rules, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Regarding claim 12, Spitznagel does not appear to explicitly disclose, but Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing wherein the rules engine determines an outcome value of a specific rule in real time, as facts or metadata are updated, to output the outcome value to the user (Column 4, lines 39-65, column 7, lines 7-36, column 8, lines 1-37, column 11, lines 36-67 and column 12, lines 36-65 discuss that the system determines an outcome value, such as an error code and suggested quality measure code as soon as a process is run to output the outcome value to the user for corrective action, construed as in real time and as facts or metadata is updated.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the invention/filing to modify the system of Spitznagel to such that the rules engine determines an outcome value of a specific rule in real time to output the outcome value to the user, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Regarding claim 13, Spitznagel does not appear to explicitly disclose, but Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the invention/filing wherein the system generates an output report in response to all objects for which the user has associated facts (Fig. 4C, column 4, lines 39-65, column 7, lines 7-36, column 8, lines 1-37, column 11, lines 36-65 and column 12, lines 36-65 discuss that the system generates a report for all patients for which the demographic data has been associated and which meet the rules.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the invention/filing to modify the system of Spitznagel to such that the system generates an output report in response to all objects for which the user has associated facts, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Regarding claim 14, Spitznagel discloses an automated review system for providing Abstract and paragraphs [0021]-[0022], [0030] and [0140]-[0141] discus a system for making automatically derive billing codes from a patient encounter to automatically provide a review of the patient care, such as a review of medical billing codes.) comprising:
a processor (Paragraphs [0033] and [0142]);
a provider input device for inputting provider input patient data (Paragraphs [0031] and [0037] discuss the system including a data input system, such as a keyboard and associated user interface/word processing system, for inputting patient data.),
a patient database comprising patient data and the provider input patient data (Paragraphs [0026], [0030], [0105] and [0142] discuss that the system includes a database for storing structured medical facts related to a patient such as provider inputted data and patient history data.),
a rules engine, executing on the processor, the rules engine in communication with the patient database (Fig. 1 and paragraphs [0033] and [0142] show and discuss a computer having a processor in communication with the user interface, input devices and a database.),
the rules engine configured for and traversing a plurality of Paragraphs [0021]-[0022], [0078]-[0079], [0105], [0108] and [0119]-[0120] discuss that the system/processor includes a natural language understand (NLU) engine which is in communication with the various components of the system, including the data input device and the patient database. The NLU engine includes traverses medical code rules based on inputted patient data from the database of stored structured medical facts to generate a review of patient care detailing suggest medical billing codes for submitting a bill.),
wherein the patient data is a structures descriptive data (Paragraphs [0026], [0030], [0105] and [0142] discuss that the system includes a database for storing structured medical facts related to a patient, construed as structured descriptive data items.; and
a data output system (Fig. 1, user interface),
Spitznagel further discloses that the medical billing codes for submitting reports for billing may include codes mandated by the Centers for Medicare and Medicaid Services (Paragraphs [0005]-[0006]), but does not appear to explicitly disclose: a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree; wherein the provider input patient data comprises age and patient insurance; wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance; the rules engine configured for and traversing a plurality of denominator and numerator rules, using both provider input patient data and patient data from the patient database to generate, from multiple encounter and multiple measures; wherein the review of patient care comprises the one or more quality measures; wherein a quality measure is displayed in real time using the data output system as the patient data is entered, wherein the quality measure is calculated in real time; or wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules,
However, Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing to provide an system for providing multiple-measure review of patient care (Column 1, lines 13-18, column 2, lines 16-34, column 3, lines 39-65, column 7, lines 7-36, column 8, lines 1-37, column 11, lines 36-65 and column 12, lines 36-65 discuss an automated system for generating quality measure reports for multiple quality measures to comply with the Physician Quality Reporting Initiatives.);
a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree (Figs. 6A-6C shows the logical routine for the quality measure/specified data records selection (i.e. patient eligibility) and the algorithms/rules for the denominator determination and numerator determination used to automatically determine quality measures and that the rules are in a hierarchical tree format. Also see column 4, lines 28-38, column 7, lines 7-36, column 8, lines 1-37, column 11, lines 36-65, column 12, lines 36-67 and column 13, lines 1-12 and Tables I-III.);
wherein the provider input patient data comprises age and patient insurance; wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance (Column 5, lines 19-63 discuss the practice management module automatically selects patient data records for the quality measurement evaluation based on matching information in the patient data records with information for the quality measure, such as age, sex and insurance. The patient data records may be entered and updated by providers as discussed in column 5, lines 8-15.);
a rules engine configured for traversing a plurality of denominator and numerator rules to generate the review of patient care from multiple encounters and multiple measures, wherein the review of patient care comprises the one or more quality measures; wherein the review of patient care comprises the one or more quality measures (Column 4, lines 28-38, column 7, lines 7-36, column 8, lines 1-37, column 11, lines 36-65, column 12, lines 36-6 and column 13, lines 6-12 discuss an automated computer system having logical routines which uses rules to traverse denominator rules and numerator rules using patient demographic data. For example, the system uses rules and patient data to first traverse denominator rules to determine if the patient meets the denominator reporting requirements and then traverse numerator rules to determine if the patient meets the numerator reporting requirements. The results are used to generate a report for multiple patient records/encounters and may be user for multiple quality measures. Stanley also uses true-false or yes-no determinations using patient data for specific quality measure rules. Also see figs. 4C and 6A-6C and Tables I-III, these rules are in a hierarchical tree format.); and
wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules (Column 4, lines 28-38 and 66-67, column 5, lines 1-17, column 7, lines 7-36, column 8, lines 1-37 and column 13, lines 6-12 discuss an automated computer system having logical routines which used rules to traverse hierarchical tree of denominator questions and numerator questions using patient structured demographic data to determine if the demographic data meets the requirements of the rules. Structured demographic data is construed as medical facts having associated metadata. As shown in figs. 6A-6C and Tables I-III, these rules are in a hierarchical tree format.) to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the reporting of the care to the patients' insurance providers (Column 3, lines 36-48).
Therefore, it would have been obvious to one of ordinary skill in the art of quality performance measurement reporting at the time of the filing to modify the system of Spitznagel: such that the system is for providing multiple-measure review of patient care; to include a logic block executing on the processor, the logic block configured to automatically determine one or more quality measures, if a patient is eligible, wherein each quality measure comprises a set of attributes and a set of denominator and numerator questions in a hierarchical tree; wherein the provider input patient data comprises age and patient insurance; wherein eligibility for a quality measure calculation is determined automatically based on patient age and patient insurance; to include a rules engine configured for traversing a plurality of denominator and numerator rules to generate the review of patient care from multiple encounters and multiple measures, wherein the review of patient care comprises the one or more quality measures; wherein the review of patient care comprises the one or more quality measures; and wherein the rules engine examines the facts associated with the specific object and applies a hierarchical tree of rules to metadata assigned to the facts to determine if the facts meet requirements of the rules, as taught by Stanley, in order to assist providers with an automated tool to manage the information and provide a knowledge-based process for managing the care of patients and the quality measure reporting of the care to the patients' insurance providers.
Spitznagel as modified by Stanley does not appear to explicitly disclose wherein a quality measure is displayed in real time using the data output system as the patient data is entered, wherein the quality measure is calculated in real time; or wherein each quality measure is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure.
Sublett teaches that it was old and well known in the art healthcare quality measures at the time of the filing that a quality measure is displayed in real time using the data output system as the patient data is entered, wherein the quality measure is calculated in real time (Paragraphs [0044]-[0050], [0066]-[0068] and [0135] discuss providing real-time KPI dashboards which should real-time patient data and performance information as it is made available to the system, such as quality measure information as shown in Figs. 13-14. Also see paragraphs [0106]-[0108].); and
wherein each quality measure is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure (Paragraph [0115], selection of an item on the interface 1300 provides further information regarding that item to the user. Paragraph [0120], for a particular measure 1501, additional detail is displayed to the user such as a stratum for the measure (patients age 3-11 in this example), an explanation of the numerator (patients who had a height, weight and body mass index percentile recorded during the measurement period in this example). Paragraph [0121], via the interface(s) 1300, 1400, 1500 a user can see which measures the user passed or failed and can drill in to see what is happening with each particular measure and/or group of measures. Paragraph [0122], an interface for a user to select a set of measures/requirements (e.g., MU, PQRS, etc.) and then select which measures he or she is going to track. Only those selected measures appear in the dashboard for that provider, for example. Also see paragraph [0123] and figs. 13-15.) to help improve departmental operations and streamline reimbursement documentation, support, and processing (Paragraph [0045]).
Therefore, it would have been obvious to one of ordinary skill in the art of healthcare quality measures at the time of the filing to modify the system of Spitznagel as modified by Stanley such a quality measure is displayed in real time using the data output system as the patient data is entered, wherein the quality measure is calculated in real time; and wherein each quality measure is a link, the link displays how quality measure is calculated and wherein user is given option to override automated calculation of quality measure, as taught by Sublett, in order to help improve departmental operations and streamline reimbursement documentation, support, and processing.
Regarding claim 15, Spitznagel does not appear to explicitly disclose, but Stanley teaches that it was old and well known in the art of quality performance measurement reporting at the time of the filing wherein the review is automatically provided to a Provider Quality Reporting