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 status of the claims as of the response filed 12/09/2025 is as follows: Claims 1-10 are pending. Claims none are canceled. The applicant has amended Claims 1-5 and 7-10, which are considered below. Claim 6 is original.
Applicant Argument Response:
Examiner considers the applicant's arguments filed on 12/09/2025 regarding the pending claims 1-10 to be unpersuasive and sustains the 35 U.S.C. § 101 subject-matter eligibility rejection.
Applicant argues that the amended claims include specific technical elements: an NLP module with data normalization, a master knowledge graph for explainable AI, modular stack block layers, and structured feedback processing. These elements provide concrete improvements to computer functionality by enhancing data accuracy and system explainability. The improvements also enable a scalable modular architecture for independent operation. Ultimately, these features offer specific technological solutions to healthcare data-processing challenges, moving beyond generic computer implementations.
The examiner respectfully disagreed because the claims, under the broadest reasonable interpretation, describe an information-analysis and judgment workflow (receiving, parsing, identifying, generating recommendations, and revising from feedback) that remains abstract. The specification describes a knowledge graph and general computing infrastructure without demonstrating a specific technical improvement to computer operation, NLP, or graph-processing technology itself. Reciting AI tools or better analytical accuracy does not integrate the abstract idea into a practical application; eligibility requires an improvement to the underlying technology, which these claims do not show.
Examiner considers the applicant's arguments filed on 12/09/2025, pages 8-13, regarding the pending claims 1-10 to be unpersuasive and sustained the 35 U.S.C. § 102 rejection;
The applicant’s amendments and remarks have been fully considered. The examiner agrees that the amendments to certain claims (specifically Claims 3, 4, 6, 9, and 10) successfully overcome the previous anticipation rejection under 35 U.S.C. § 102 based on Katwala. Specifically, Katwala does not explicitly disclose the newly added limitations, such as the independent modular stack block architecture, the conversion of standardized formats (e.g., HL7, FHIR), and the automatic consolidation of feedback to create new rules.
Accordingly, the § 102 rejection for these specific claims is withdrawn. However, to the extent that the amendments overcome the anticipation rejection, these claims are now subject to a New Ground of Rejection under 35 U.S.C. § 103. The newly recited features are rendered obvious by Katwala in combination with newly cited prior art references (Mobarakeh and Swanson), which explicitly teach the modular architecture and automated rule-creation limitations missing from Katwala.
Applicant argues that Claim 1, "A computer-implemented method for calculating a risk adjustment factor RAF by a risk adjustment workflow system, comprising" is not properly rejected because the amendments allegedly render the prior rejection moot and Katwala does not teach or suggest the newly recited features.
Examiner:
Katwala describes a risk adjustment workflow system that processes both unstructured and structured patient-related data in par. 0029, fig. 1A, 0034 and 0104. The system utilizes Natural Language Processing (NLP) to parse unstructured data into segments such as sections, paragraphs, sentences, or words, normalizing the input according to clinical rules. The parsed data is then sent to a data engine that uses a semantic health taxonomy acting as a master knowledge graph to create and enrich concepts and relationships, providing an explainable clinical context for disease diagnoses. These findings are presented to a coder through an interactive interface that displays the proposed ICD-10 code, supporting evidence, and the resulting RAF adjustment, enabling the coder to accept, reject, or review the suggestions. The system continuously improves by incorporating coder feedback to define new concepts and update clinical rules within the taxonomy, enhancing the accuracy and utility of the risk adjustment factor. Refer to 35 U.S.C 102 rejection below
Applicant argues that Claim 1, "receiving an input... by a retrospective workflow" and "providing... an output... by a prospective workflow," is not properly rejected because Katwala allegedly fails to teach an integration of retrospective and prospective modular workflows with iterative machine learning in response to a failed data enrichment process.
The examiner disagreed because, under proper BRI, Claim 1's "retrospective workflow" and "prospective workflow" refer to processing past data to identify clinical entities and providing outputs for future action, without requiring unrecited "modular" or "iterative machine learning" features. The applicant’s argument was unpersuasive because anticipation cannot be overcome by features not recited in the claim, and Katwala's disclosure of analyzing historical records and current health data already covers these broadly claimed features. Refer to 35 U.S.C 102 rejection below Katwala fig. 1A, par. 0029, par. 0104-0106, 0112-0114, 0121, fig. 16 and 20 .
Applicant argues that "updated dynamically through the feedback processing module with automatic consolidation of related feedback and creation of new rules" is not properly rejected because Katwala merely suggests coding opportunities and fails to teach continuous system improvement through automated feedback consolidation.
The Examiner respectfully disagreed because under proper BRI, Claim 1, "updating, based on the feedback received by the coder, the Application Recommendation System by adding a new rule therein" means modifying the system logic based on user input, which does not require the unrecited limitation of automatic consolidation. Unrecited limitations cannot overcome an anticipation rejection for Claim 1.
Applicant argues that Claim 1, "providing, based on the processing by the Application Recommendation System, an output comprising ICD-10-CM codes, description, diagnosis evidence, MEAT evidence, cross-walk to HCC codes, and RAF score of HCC codes by a prospective workflow to a coder," is not properly rejected because Katwala allegedly fails to disclose performing comparative and predictive 360-degree longitudinal data analysis to connect abnormal indicators.
The Examiner respectfully disagreed because under proper BRI, Claim 1 simply means generating and displaying the explicitly listed codes, evidence, and scores to a coder for curation, without requiring the unrecited "360-degree longitudinal data analysis" or "abnormal indicators" limitations. The examiner found the applicant's position not persuasive because a rejection cannot be overcome by arguing features that are not actually recited in the claim; the record shows Katwala [par. 0038, 0031, 0121, 0103, 0106, 0112-0114 and fig. 16] expressly discloses presenting an output that includes ICD-10-CM codes, MEAT review, HCC translations, and RAF impacts to a human coder for curation tasks. Therefore, the rejection is maintained.
Applicant argues that Claims 2, 3, and 9 are not properly rejected because Katwala allegedly relies on manual classification and fails to teach automatic claim comparison, modular stack block architecture, or capturing coder interactions as training feedback. Answer
The Examiner respectfully disagreed because under proper BRI, classifying conditions by comparing current codes with previous claims is taught by Katwala's. The examiner found the applicant's position unpersuasive because it is now moot based on the current obviousness rejections explicitly rely on Mobarakeh to teach the interoperable modular architecture and on Swanson to teach modifying interpretation rules using consolidated coding feedback. Therefore, the rejection is maintained.
Examiner considers the applicant's arguments filed on 12/09/2025, page 13-14, regarding the pending claims 1-10 to be persuasive in view that Katwala and Pang does not make obvious claims 3 and 10 and withdraw the 35 U.S.C. § 103 rejection; however, submits a 35 U.S.C. § 103 rejection to overcome the applicant's amendments.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5 and 7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Indefinite Terms:
Claim 5 recites "a large network," Claim 7 recites "easily validated," without defining an objective baseline.
Examiner's Interpretation for Compact Prosecution: However, for the purpose of compact prosecution, an examiner must give the claims their broadest reasonable interpretation in view of the specification to facilitate examination of the claims over the prior art. Accordingly, the examiner interprets these indefinite terms as follows:
"a large network." Under BRI, this encompasses any substantial, interconnected data structure linking clinical entities and their properties. Refer par. 0043
"easily validated." This broadly means the system's outputs are auditable by a user through provided evidence or reasoning, rather than being an opaque black box. Refer par. 0018 and 0077
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.
Subject Matter Eligibility Rejection
Claims 1-10 are rejected under 35 U.S.C. § 101 because the claimed subject matter is directed to a judicial exception (an abstract idea) without reciting elements that integrate the exception into a practical application or provide an inventive concept amounting to significantly more than the exception itself.
Step 1: Statutory Categories Analysis
The claims are directed to statutory subject matter, encompassing the following statutory categories:
Process (Claims 1-9): The language reciting receiving an input... parsing... identifying... providing... updating defines a series of acts or steps, aligning with the definition of a process in MPEP 2106.03. Machine (Claim 10): The language reciting one or more processors and one or more computer-readable storage devices describes a concrete thing consisting of parts, aligning with the definition of a machine in MPEP 2106.03.
Having confirmed that the claims are directed to statutory subject matter, the analysis proceeds to Step 2A, Prong 1.
Prong One:
Step 2A, Prong One determines if the claims recite a judicial exception.
The invention relates to a risk adjustment solution workflow for proactively identifying a patient's chronic conditions and projecting a risk adjustment factor.
Recitation of representative Claim 1, to identify abstract idea (non-bold), and additional elements (bold, further evaluate in prong two and step 2B).
Claim 1.
A computer-implemented method for calculating a risk
adjustment factor (RAF) by a risk adjustment workflow system, comprising:
receiving an input including a structured data and an unstructured data by a
retrospective workflow to identify one or more clinical entities;
parsing the unstructured data format into the structured data format by a Natural
Language Processing (NLP) module configured to identify sections, sentences, entities,
metadata, attributes, status, and negation and normalizing the data based on specific use
case, and passing said parsed structured data and the input unstructured data to an
Application Recommendation System;
identifying, based upon the unstructured data, an evidence by the Application
Recommendation System and processing said evidence based on an input received from
a master knowledge graph module that provides clinical context and relations with other
entities to create an explainable AI system;
providing, based on the processing by the Application Recommendation System,
an output comprising ICD-10-CM codes, description, diagnosis evidence, MEAT
evidence, cross-walk to HCC codes, and RAF score of HCC codes by a prospective
workflow to a coder, wherein the coder performs a plurality of curation tasks to provide
a feedback to a feedback processing module; and
updating, based on the feedback received by the coder, the Application
Recommendation System by adding a new rule therein and fine-tuning the risk adjustment workflow system to improve accuracy in projecting a risk adjustment factor.
Independent Claims 1 and 10 Abstract Classification Rational
Independent claims 1 and 10 recite an abstract idea in the form of a mental process. Under the broadest reasonable interpretation, the claims recite receiving structured and unstructured clinical data, parsing and normalizing the data, identifying clinical entities and evidence, evaluating that evidence using clinical context and relationships, generating coding and risk-adjustment output, presenting that output to a coder for review, receiving coder feedback, and revising the decision criteria by adding a new rule and fine-tuning based on that feedback.
These limitations describe collecting information, organizing and evaluating that information, making coding and risk-adjustment determinations from the information, presenting the results for human review, and revising the criteria used for later determinations, which are acts of observation, evaluation, judgment, and opinion within the mental-process grouping. See MPEP 2106.04(a)(2), subsection III.
For example, a human reviewer could read structured fields and narrative notes in a patient chart, extract and organize relevant clinical entities and supporting evidence on paper, apply written coding and clinical-context rules to suggest ICD-10-CM codes, diagnosis evidence, MEAT evidence, HCC-related output, and a RAF-related conclusion, obtain coder feedback on those suggestions, and then revise the written rules for future cases by adding a new rule based on that feedback. Thus, under its broadest reasonable interpretation, the claim covers acts that can practically be performed in the human mind or with pen and paper, even though the claim states that computerized modules are used.
Dependent Claims Abstract Idea Rational:
The dependent claims 2-9 are also directed to an abstract idea.
Dependent claims 2-9 are also directed to an abstract idea because each claim further limits the same underlying process of reviewing patient and claims information, comparing and classifying conditions, generating coding-related recommendations, obtaining human review or feedback, and revising recommendation criteria based on that feedback. Under the broadest reasonable interpretation, these added limitations remain acts of collecting information, organizing it, comparing it, evaluating it, making judgments from it, and revising later determinations, which fall within the mental-process grouping of abstract ideas.
Accordingly, claims 1-10 recite abstract ideas in the form of mental processes, namely collecting patient and claims information, organizing and comparing that information, identifying evidence and conditions, generating coding and RAF-related recommendations, obtaining coder feedback, and revising decision criteria based on that feedback; the analysis therefore turns to Step 2A, Prong Two to determine whether the claims integrate that abstract idea into a practical application.
Step 2A, Prong Two: Integration into a Practical Application
Step 2A, Prong Two asks whether the claim as a whole uses the recited abstract idea in a manner that imposes a meaningful limit on that abstract idea, rather than merely carrying it out in a computer setting.
Evaluation of independent Claims 1 and 10 Additional Elements
For independent claims 1 and 10, the additional elements beyond the abstract idea are the computer-implemented method/system context, the risk adjustment workflow system, the Natural Language Processing (NLP) module, the Application Recommendation System, the master knowledge graph module, the explainable AI system language of claim 1the feedback processing module, and in claim 10 the one or more processors, one or more computer-readable storage devices, computer-executable instructions, and the stack-block-layer / modular-architecture limitations.
computer implementation and processing environmentThe recitation of a computer-implemented method, a system, one or more processors, one or more computer-readable storage devices, computer-executable instructions, and a risk adjustment workflow system does not overcome Prong Two because it merely places the abstract idea into a computer environment without reciting a particular technological improvement in how the computer itself operates. MPEP 2106 explains that additional elements do not integrate an exception into a practical application when they merely include instructions to implement an abstract idea on a computer or merely use a computer as a tool to perform the abstract idea. Here, claims 1 and 10 recite the computer environment at a high level of generality and then use that environment to receive data, evaluate evidence, generate coding-related output, receive feedback, and update rules; the claim language does not identify a specific improvement to processor operation, memory operation, data structure operation, or any other computer function.
NLP module, Application Recommendation System, master knowledge graph module, feedback processing module, and explainable AI systemThe recitation of the NLP module, the Application Recommendation System, the master knowledge graph module, the feedback processing module, and the explainable AI system language does not overcome Prong Two because these elements are claimed as result-oriented analytical tools for performing the same abstract evaluation and recommendation process, not as a specific technical mechanism that improves a computer or another technical field. The claim language says the NLP module identifies sections, sentences, entities, metadata, attributes, status, and negation and normalizes data; the Application Recommendation System identifies evidence and provides coding-related output; the master knowledge graph module provides clinical context and relations; and the system is said to create an explainable AI system. But the claims do not recite how any of those modules are technically implemented in a way that improves natural-language processing technology, graph processing technology, database technology, or machine-learning technology itself. Under MPEP 2106.05(a), an improvement must be to the functioning of the computer or another technology, not merely to the abstract decision process being performed, and under MPEP 2106.05(f), invoking software tools to perform the analysis is not enough by itself.
stack block layers, independently operated components, data interoperability, reusable modular architecture, and separate commercialization of sub-solutions in claim 10.
The recitation of the above additional elements does not overcome Prong Two because these limitations describe the claimed solution at the level of architectural arrangement, reuse, and deployment goals, not at the level of a specific technological mechanism that improves computer functionality or another technology. Since the claim does not recite a particular interface protocol, data structure, synchronization technique, or other concrete implementation showing how the asserted interoperability and independence are technically achieved. Under MPEP 2106.05(a), an improvement must be to the functioning of the computer or another technology, not merely to the organization or packaging of the abstract solution itself. Accordingly, these limitations do not integrate the judicial exception into a practical application.
When viewed as a whole, the combination of these elements does not integrate the judicial exception into a practical application. The claim still recites a computerized healthcare coding and risk-adjustment review workflow in which clinical data is received, organized, evaluated with context, converted into coding and RAF-related suggestions, reviewed by a coder, and then used to revise later rule application. The additional elements work together only as an environment and set of tools for carrying out that same abstract process; they do not recite a particular machine integral to the claim, a transformation of an article, a specific treatment for a medical condition, or a specific improvement in computer functionality or another technical field. MPEP 2106 directs that Prong Two considers the claim as a whole, and under that whole-claim view the present claims do not do more than apply the mental-process exception in a computer-based healthcare coding environment.
Dependent Claims Analysis
The dependent claims 2–9 do not overcome Step 2A, Prong Two. Each dependent claim either adds more detail to the same abstract information-review and coding workflow, limits that workflow to a particular healthcare data or coding environment, or recites software-oriented labels and desired results without a specific technical mechanism that improves computer functionality or another technology. MPEP 2106 directs that Prong Two asks whether the additional elements, individually and in combination, meaningfully limit the exception by integrating it into a practical application, such as by reciting a technological improvement reflected in the claim itself.
Claims 2, 7, 8, and 9 do not require a separate Prong Two additional-element analysis because they do not recite a new additional element beyond what was already addressed in the independent claims. Instead, they merely add more detail to the same abstract reviewing, comparing, analyzing, recommending, explaining, and feedback-based revising process, or merely narrow the healthcare data environment in which that abstract idea is performed. Those limitations therefore do not change the Prong Two result.
Claims 4 and 6 fail to overcome Step 2A, Prong Two, because they only add further detail about the input data types, sources, and generic preparation methods for the abstract review-and-recommendation process. The claims recite gathering various health data (e.g., medical charts, lab reports) and preprocessing it using generic tools like OCR and format conversion for standard data types (HL7, FHIR, CCDA). These limitations do not constitute a practical application or a technological improvement, as they merely describe data intake and generic preparation to feed the abstract analysis. Under MPEP § 2106, mere data gathering and pre-solution activity using conventional functions do not meaningfully limit a judicial exception.
Claim 3 adds architectural organization, namely workflows “connected as modular stack block layers,” which fails to improve computer functionality under MPEP 2106.05(a). The claim recites modularity and interoperability as desired architectural results, but does not recite a specific technical mechanism showing how that arrangement improves computer operation or another technical field.
Claim 5 adds a graph/network-style relationship structure, namely creating “a large network of entities and their properties,” which also fails to improve computer functionality under MPEP 2106.05(a). The claim recites the informational result of adding context and relationships for clinical decision support, but does not recite a specific technical mechanism that improves graph processing, storage, retrieval, or another technology.When viewed as a whole, the combination of the dependent-claim and independent-claim elements does not pass Prong Two. The claims still use computing components, software labels, workflow architecture, and healthcare data as tools and context for carrying out the same abstract idea, rather than reciting a specific technical solution to a technical problem.
Because the dependent claims do not add a specific technological mechanism that integrates the abstract idea into a practical application, the claims do not overcome Step 2A, Prong Two, and the analysis proceeds to Step 2B.
Step 2B
Step 2b determines if the claim as a whole amounts to significantly more than the exception itself according to MPEP 2106. The additional elements do not overcome step 2b.
The additional element, for claim 1, the computer-implemented method context, risk adjustment workflow system, retrospective workflow, prospective workflow, NLP module, Application Recommendation System, master knowledge graph module, explainable AI language, and feedback processing module; and, for claim 10, those same features plus one or more processors, one or more computer-readable storage devices, computer-executable instructions, and stack-block / modular-architecture limitations. Step 2B evaluates those same elements individually and in combination.
Independent claims 1 and 10
computer implementation, processors, storage devices, executable instructions, and risk adjustment workflow system
The claims' reliance on generic computer elements, such as "computer-implemented," "one or more processors," and "computer-executable instructions," does not introduce an inventive concept. This is because the claims merely place an abstract review-and-recommendation process on a computer without reciting a particular computing technique that changes how the computer functions. The specification confirms that the disclosure is about an implementation platform for executing the workflow, not an improvement to the computing function. Therefore, using these computer components as the environment for the abstract process does not amount to "significantly more." Refer to MPEP 2106.05(f) and Spec., para. [0081]
NLP module, Application Recommendation System, master knowledge graph module, feedback processing module, and explainable AI language
The recited modules, encompassing the Natural Language Processing (NLP) module, the Application Recommendation System, the master knowledge graph, and the explainable AI, do not contribute an inventive concept as the claims articulate their functions solely at an abstract level. The claims are deficient in specifying any particular technical solution, which would constitute an improvement to the underlying technology itself. The specification corroborates this assessment by characterizing the modules as instruments for general contextual information processing and auditable output, rather than as described technological advancements. Consequently, the reliance upon these modules merely to execute abstract analysis does not satisfy the requirement of "significantly more."Reer to Spec, par. 0018, 0077, and mpep 2106.05(a/f)
stack-block layers, independent operation, interoperability, reusable components, and separate commercialization
The recitation of the additional elements above does not add significantly more than the abstract idea. As in Prong Two, these limitations recite high-level modular organization and business flexibility, but not a specific technical implementation that changes how the computer functions or solves a technological problem in an unconventional way. The specification describes the approach in terms of standalone presentation, reuse of “components, logic and flow,” and separate commercialization of sub-solutions, which shows organizational and deployment objectives rather than an inventive computing technique. Spec. [0013], [0075], [0079]-[0080]. Refer MPEP 2106.05(a)
Viewed together, the additional elements in claims 1 and 10 still leave the claims as a computerized healthcare coding and reimbursement review workflow that receives data, organizes it, evaluates it, generates coding and RAF suggestions, presents them for coder review, and updates later rule application. Step 2B does not change the Prong Two result because the same elements remain only computer implementation, software-labeled tools, workflow setting, human review, output, and modular organization. None transforms the claim into a technical solution to a technical problem, and together they still do not amount to significantly more than the abstract idea itself.
Dependent claims
Claims 2, 7, 8, and 9 do not require a separate step 2B analysis because they do not recite a new additional element beyond what was already addressed in the independent claims. Instead, they merely add more detail to the same abstract reviewing, comparing, analyzing, recommending, explaining, and feedback-based revising process, or merely narrow the healthcare data environment in which that abstract idea is performed. Those limitations therefore do not change the step 2B result.
Claims 4 and 6 add only data-source and preprocessing limitations, including particular categories of patient/claims data, scanned and machine-readable documents, OCR, format conversion, and retrieval of structured data from EHR/HIE systems. These limitations do not overcome step 2B because they merely gather and prepare information for use in the same abstract coding and risk-adjustment analysis, without reciting a specific OCR technique, conversion mechanism, interoperability architecture, or other technological improvement. For the same reasons, these limitations do not add significantly more under Step 2B, because they remain generic pre-solution data-acquisition and preprocessing activity used as tools to perform the abstract idea.
Claim 3
Claim 3 adds modular stack block layers, independent operation, interoperability, and reusable logic and flow. The best fit rationale is MPEP 2106.05(a), for the same reason as claim 10’s stack-block architecture: the claim recites organizational architecture and desired results, but not a specific technical mechanism that improves computer functionality or another technology.
Claim 5
Claim 5 adds a graph-style network of entities and their properties for clinical decision support. The best-fit rationale is MPEP 2106.05(a) because the claim recites an informational result and contextual support for decision-making, not a specific graph-processing mechanism that improves technology. The specification describes the knowledge graph as a large network of entities (subjects, objects), and their properties (relationships) used for organizing information in a structured way and making sense and meaning of its data. Spec., para. [0043]. That is still information organization in service of the same abstract clinical decision workflow, not a specific technical improvement to graph storage, retrieval, or traversal. Claim 5 therefore does not add significantly more.
Carried forward consistently from BRI, Prong One, and Prong Two, the additional elements in claims 1 to 10, individually and in combination, do not amount to significantly more than the single abstract idea already identified. Therefore, Step 2B is NO, and claims 1 to 10 remain rejected under 35 U.S.C. 101.
Claims 1 and 10, despite additional elements like computer settings, software-labeled modules, and workflow labels, fail Step 2B because these elements merely implement the previously identified abstract healthcare coding and risk-adjustment review process on general computing infrastructure without a specific technical improvement. Claims 2, 4, 6, 7, 8, and 9 only narrow this abstract process, and claims 3 and 5 add only high-level modular architecture and knowledge-graph organization without a recited technical improvement. As a result, the entire claim set lacks an inventive concept and is not significantly more than the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 5, 7-8 are rejected under 35 U.S.C. 102(a)(1) as being anticipate over US20180046764A1-Katwala.
Claim 1.
Katwala teaches, A computer-implemented method for calculating a risk adjustment factor (RAF) by a risk adjustment workflow system, comprising: (Katwala, par. 0104)
receiving an input including a structured data and an unstructured data by a retrospective workflow to identify one or more clinical entities; (Katwala, fig. 1A, par. 0029)
Katwala’s system receives both structured (like EMR and claims data) and unstructured (like free-text documents) patient information and reviews all previous records to identify and capture any missed clinical diagnoses.
parsing the unstructured data format into the structured data format by a Natural Language Processing (NLP) module configured to identify sections, sentences, entities,
metadata, attributes, status, and negation and normalizing the data based on specific use
case, and passing said parsed structured data and the input unstructured data to an Application Recommendation System; (Katwala, fig. 1A, par. 0029, 0034 “unstructured patient-related data 102 and structured patient-related data 104 … are inputs to data engine 106, which is used to generate processed and enriched patient-related data 108 based on the input data”, 0036 “include… normalization… using clinical rules and other types of rules…is the original document 102… the enriched data 108 is the original document 102 or 104 along with additional metada…, 0050, 0102, 0049 “ varying levels of granularity… sections, sentence…words…tokens“, figure 5. “Identify candidate entities”, par. 0043 “each concept…is associated with one or more concept attributes”, par. 0061 “include , for example , a negation annotator” abstract “using natural language processing and a semantic health taxonomy“, fig. 2 “create and augment concepts and semantics relationships between concepts”, par. 0061 “ determine…test result is withing the normal range…“ par.0053 “select proposed medical codes based on patient documents for a particular patient”, par. 0059 “..to avoid attributing to a patient a
disease or condition supported…par. 0049 )
Katwala’s system uses NLP parsing step that converts free-text clinical documents into structured elements usable by the engine, and passes the parsed/structured and unstructured patient data to a data engine 106.
identifying, based upon the unstructured data, an evidence by the Application Recommendation System and processing said evidence based on an input received from a master knowledge graph module that provides clinical context and relations with other entities to create an explainable AI system; (Katwala, paragraphs 0029, 0034-0036, 0038-0039 0053, 0046, 0049-0050, 0105, Fig. 1A).
Katwala, data engine identifies evidence from the unstructured documents and processed using the semantic taxonomy and clinical rules to output recommendations supported by references from the source documents.
providing, based on the processing by the Application Recommendation System, an output by comprising ICD-10-CM codes, description, diagnosis evidence,MEAT evidence, cross-walk to HCC codes, and RAF score of HCC codes a prospective workflow to a coder, wherein the coder performs a plurality of curation tasks to provide a feedback to a feedback processing module; (Katwala, paragraphs 0104, 0105 “...ICD - 10 code for Parkinson ' s Disease …the evidence for the proposed code … is shown in panel 902…”, 0106, 0112-0113, fig. 20, 0121 “shows the translation of a first type of medical code to a second type…; par. 0031 “...estimates for how confirming the codes affect..”, par. 0106 “Does not meet the M.E.A.T. Criteria”, par. 0038, 0031, 0121, 0103, 0106, 0112-0114 and fig. 16).
Katwala describes presenting an output of proposed diagnosis codes (coding opportunities) generated by the system to a human coder via a user interface, where the coder interacts with the results to perform curation tasks and provide feedback. Where Katwala's system provides a panel displaying proposed codes (output) ordered by RAF adjustment. The interface includes controls for the coder to accept, reject, or review the suggestion (curation tasks). The coder can also create new codes or add evidence, which constitutes feedback recorded by the system.
and updating, based on the feedback received by the coder, the Application Recommendation System by adding a new rule therein and fine-tuning the risk adjustment workflow system to improve accuracy in projecting a risk adjustment factor.. (Katwala, par. 0041-0042, 0104-0106, 0030-0031, 0003)
The system allows the addition of new clinical rules by incorporating guidelines and associating them with concepts in the semantic taxonomy, and fine-tunes the risk adjustment factor (RAF) by dynamically updating it based on evidence from multiple documents to ensure accurate patient risk assessments.
Claim 2.
Katwala, teaches the method of claim 1, wherein the retrospective workflow comprises the steps of:
analysing a previous health data of the preceding two years to identify one or more previous Hierarchical Category Codes (HCC) codes from one or more morbidity (ICD-10-CM) codes by a chart review component that processes clinical input documents through the NLP module to identify clinical entities with their attributes, status, and context to produce explainable output suggestions for user curation; (Katwala, paragraphs 0031, 0102-0104-0107, 0115, fig. 9, 15, par. 0049-0050, 0059-0061, 0121, 0060-0061).
Katwala describes a system directed to retrospective chart review for risk adjustment coding that analyzes a patient’s historical medical records to identify previously coded chronic conditions (HCC-related diagnoses) and missed codes. Where Katwala's interface presents an “HCC Summary” listing HCC conditions and the years they were coded. Katwala helps the user review past documents to confirm existing codes and find un-coded conditions. Katwala retrieves the patient’s previously documented ICD-10 codes and maps them to HCC categories. While Katwala does not explicitly limit the look-back period to two years, selecting a two-year window is a routine design choice in risk adjustment workflows. Implementing a two-year cutoff in Katwala is merely limiting the data scope, just descriptive matter and would yield predictable results.
and identifying, based on a comparison of the identified previous HCC codes with one or more previously filed claims, a claim condition selected from a properly claimed condition, an unclaimed condition, or an overlooked claimed condition, by a chart audit component, that automatically categorizes codes for potential add or delete recommendations providing both potential adds and potential deletes in the same tool, and (Katwala, paragraphs 0031,0111- 0112, , abstract, 0102, 0120, 0104, 0106, 0111, 0115, fig. 9).
Katwala describes a functionality to determine whether a condition has been properly coded in claims by comparing the patient’s documented conditions against what has been billed (chart audit). Where Katwala’s interface allows the coder to mark a proposed code with statuses like “Already billed for the current plan year” (properly claimed), or “Incorrect inference/not supported” (overlooked claimed condition). By surfacing “Open Opportunities” (unclaimed conditions) (FIG. 9) and noting which conditions are already claimed, Katwala distinguishes between these categories. Katwala’s review includes correcting miscoded conditions/services.
and the prospective workflow comprises the steps of: analysing a current health data of the current year to identify one or more current HCC codes from one or more ICD-10-CM codes and one or more previously filed claims by employing 360-degree longitudinal data analysis; (Katwala, fig. 9,15, 0100, 0104, 0102, 0106, 0108, 0123, 0121, 0031, 0034-0035, 0103-0105, 0117-0119, 0094 ).
Katwala describes a system that performs a forward-looking analysis (prospective workflow) by evaluating the patient’s current health data to identify which HCC conditions should be addressed. Where Katwala’s interface presents “suspected diseases or conditions” based on the chart and predictive models. These suggestions are current HCC coding opportunities. Katwala orders proposed codes by their RAF impact. Katwala considers both the new clinical data and what was previously claimed, as evidenced by comments like “Already billed for the current plan year”.
and identifying, based on a comparison of the identified current HCC codes with one or more previously filed claims, a chronic health condition selected from an existing condition, an opportunity condition, and a risk condition wherein the system automatically connects abnormal indicators through the clinical knowledge graph to suggest overlooked emerging conditions. (Katwala, par. 0029, 0034-0035, 0039, 0049-0050, 0100, 0102-0106, 0108, 0111, 0120-0121,0093, fig.9 and fig. 15)
Katwala teaches comparing current coding status against prior claims and coding history using insurance claim documents to identify existing conditions (already coded) and opportunity conditions (suspected or proposed codes not yet associated with the patient, often related to HCC/RAF). The system also supports a risk condition as proposed codes are tied to patient risk assessment. Furthermore, the system uses a semantic taxonomy to infer overlooked conditions from related abnormal indicators, such as associating diabetic retinopathy and acanthosis nigricans with Type II Diabetes.
Claim 5.
Katwala teaches the method of claim 1, wherein the input data of the master knowledge graph is processed by the NLP module to add clinical context and relations with a plurality of entities provided by the master knowledge graph to create a large
network of entities and their properties for clinical decision support. (Katwala, paragraph0029, 0035-0036, 0039, 0041, 0043-0045, 0050, 0053, 0060).
Katwala teaches a workflow where patient data is run through natural language processing and then enriched using a semantic taxonomy that links document text to clinical concepts and defines how those concepts are related. By building this connected network, the system can automatically infer additional conditions (for example, Type II Diabetes from related findings) and use those in clinical decision-making, including coding and care recommendations.
Claim 7.
Katwala, teachess, The method of claim 1, wherein the Application Recommendation System is an ICD-10-CM code recommendation system configured to automatically analyze processed structured and unstructured patient data thereby making the system auditable and easily validated by providing explainable AI output with supporting evidence and justification for each suggested diagnosis code.
. (Katwala, paragraphs 0044, 0105, 0062, 0031, 0034, 0036, 0103, 0105, 0106, 0122).
Katwala teaches an automated diagnosis-code recommendation system that processes structured and unstructured patient data, generates proposed diagnosis codes, and presents each proposed code together with code-specific supporting evidence and reviewer-facing documentation.
Claim 8.
Katwala, teaches, The method of claim 1, wherein the coder performs one or more curation tasks selected from the tasks of accepting the output provided by the prospective workflow; (Katwala, par. 0103-0104, 0106, 0113, 0114)
Katwala’s coder User Interface (UI) includes an action control to accept (i.e., confirm the proposed code) as part of the workflow, satisfying the acceptance task.
updating the output including editing of the code, addition of evidence or removal of evidence; (Katwala, paragraphs 0106, 0113, 0114).
Katwala describes a coder interface with controls to change a proposed code’s status and to attach or retag chart excerpts as evidence, thereby supporting editing the code’s linked evidence and removing or reassigning evidence.
rejecting the suggested output; (Katwala, paragraph 0106).
Katwala’s UI includes an explicit reject control allowing the coder to dismiss a proposed code and mark it for further review, thereby implementing a recorded rejection action.
adding new code and supporting evidence from the medical charts from the Application recommendation system to capture human interactions through the system.
. (Katwala, paragraphs 0112-0114, 0121-0122, 0114).
Katwala expressly shows a human user selecting chart text, using “window 1102” to “create a new HCC condition,” then indicating that the current chart document provides the supporting evidence, and Katwala further discloses an “activity log for changes made to the medical codes associated with a patient,” which reads on recording that a human adds action within the workflow.
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 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.
Claim 3-4 and 6 is rejected under 35 U.S.C. 103 as being unpatentable over US20180046764A1-Katwala and in view of US11456064 B2 - Mobarakeh.
Claim 3.
Katwala, teaches the method of claim 2, wherein (Katwala, para. 0058-0059, 0104, 0108, 0128)
Katwala teaches integrating both retrospective (reviewing past coding) and prospective (generating new predictions) analyses within a unified platform. However, Katwala fails to disclose wherein the retrospective workflow and the prospective workflow are connected as modular stack block layers, wherein said each workflow is configured to operate separately as an individual stack block. Katwala describes a unified system rather than explicitly separate, modular, stackable layers that operate indepdently.
Mobarakeh discloses an open, modular healthcare architecture in which PCH ECO-system functional modules, including an Integrated EHR module with an HL7/FHIR engine and Open API access, can operate independently of each other. This teaches connected modules that remain interoperable through standard data interfaces. It also teaches separately commercializable sub-solutions because the independently operating modules within this open modular architecture are structurally capable of standalone deployment and reuse. Refer to Mobarakeh, Col. 5, ll. 10-67, Col. 6, ll. 12-40, fig 12-13
A person of ordinary skill in the art would have combined Katwala with Mobarakeh to implement Katwala’s retrospective analysis and prospective coding review as distinct interoperable modules within Mobarakeh’s modular healthcare platform. The modification would have used Mobarakeh’s “HL7 and FHIR engine” and “Open API” so Katwala’s stacked coding functions could exchange patient data across connected but independently operating modules, because Katwala seeks improved coding from multiple patient-data sources and Mobarakeh teaches an “open architecture” and modules that “operate independent of each other” (Katwala [0031], [0102]; Mobarakeh Col. 5, ll. 10-67, fig. 12-14). Doing so would have predictably yielded connected workflow layers that remain interoperable for code identification and validation while being reusable and capable of standalone deployment.
Claim 4.
Katwala, teaches, The method of claim 2, wherein the previous and current health data is the health data of a patient including structured or unstructured data of the patient including medical charts, lab reports, radiology reports, claims including MAO-004 forms, pharmacy reports, durable medical equipment (DME) reports, health information exchange (HIE) data, and Hierarchical Confirmation Code (HCC) summary and the data is preprocessed through
the Natural Language Processing (NLP) module using OCR for scanned documents and
format conversion for structured data in
. (Katwala, paragraphs 0029, 0031, 0034, 0049, 0109, 0115, 0121, fig. 15, fig. 9).
Katwala teaches a multi-source, longitudinal patient-record workflow that ingests structured and unstructured data, preprocesses it with NLP (including OCR for scanned documents), and uses a semantic clinical knowledge graph plus rules to infer and surface evidence-backed coding opportunities and risk-related conditions.
Katwala, however, does not expressly specify that the structured data is converted from standardized healthcare exchange formats such as HL7, FHIR, or CCDA.
Mobarakeh discloses an Integrated EHR module that includes an HL7 and FHIR engine enabling integration with any EHR compliant with these standards and providing an Open API for access to patient records. This teaches preprocessing and format-handling of standardized healthcare exchange data because it expressly relies on HL7 and FHIR interfaces, which are structured formats used to exchange and normalize clinical data across systems.Mobarakeh Col. 5, ll. 10-67, fig. 12-14
A person of ordinary skill in the art would have combined Katwala with Mobarakeh to allow Katwala’s multi-source NLP coding platform to ingest standardized structured healthcare data in HL7 and FHIR form alongside Katwala’s existing unstructured and structured sources, so the same coding and evidence-mining workflow could operate on interoperable EHR feeds. The modification would have been to implement Katwala’s structured-data intake using Mobarakeh’s HL7/FHIR-enabled integrated EHR interface, because Katwala already relies on multiple patient-data sources to generate “processed and enriched patient-related data” and infer proposed medical codes, while Mobarakeh expressly teaches HL7/FHIR integration to access patient records (Katwala [0031], [0034], [0102], [0121]; Mobarakeh Col. 5, ll. 10-67, fig. 12-14). Doing so would have predictably improved interoperability and standardized data ingestion for Katwala’s code-identification workflow.
Claim 6.
Katwala teaches, The method of claim 1, wherein the unstructured and structured data include clinical and non-clinical data of a patient, the clinical data include health records and the non-clinical data include one or more demographic details of the patient, wherein the unstructured data includes machine-readable and scanned electronic documents, and the structured data comprises health record data in . (Katwala, paragraphs 0029, 0034, 0035-0036, 0039, 0049, 0104, 0115, 0121.)
Katwala handles both medical and non-medical patient data, including things like age and gender, and can read information from typed notes, scanned documents (optical character recognition), and electronic medical records, from health information exchanges.
However, Katwala does not teach that the structured health-record data is in HL7, FHIR, and CCDA format retrieved from an EHR system and HIE system. Mobarakeh teaches that missing feature, as shown by “an Integrated EHR module 1301 can include HL7 and FHIR engine that enables [the system] to integrate with any suitable EHR that complies with HL7 and FHIR standards,” “the Integrated EHR module provides Open API to give access to the patient’s record,” and the system may connect through “open and available relevant third-party health API to aggregate patient related data” (Mobarakeh, col. 5, ll. 10-67; col. 9, ll. 20-42; Figs. 13-14, 20, 22). This reads on structured healthcare-format retrieval from EHR/HIE-type interoperable sources because HL7/FHIR are standard health-record exchange formats and the open API/EHR integration teaches standardized retrieval of external patient records.
A person of ordinary skill in the art would have combined Katwala with Mobarakeh to allow Katwala’s multi-source coding and enrichment platform to ingest standardized structured records from interoperable EHR/HIE feeds, consistent with Katwala’s use of “structured patient-related data” and multiple patient-data sources to generate “processed and enriched patient-related data” and proposed codes (Katwala 0031, 0034, 0102), by implementing Katwala’s structured-data intake through Mobarakeh’s HL7/FHIR-enabled integrated EHR interface and open API architecture (Mobarakeh, col. 5, ll. 10-67; Fig. 13; Fig. 14). Doing so would have predictably improved interoperable retrieval and normalization of structured patient records for Katwala’s coding workflow, yielding the claimed use of structured health-record data from EHR/HIE systems in standardized exchange formats.
Claim(s) 9 are rejected under 35 U.S.C. 103 as being unpatentable over US20180046764A1-Katwala and in view of US 8,612.261 B1 - Swanson.
Claim 9.
Katwala, teaches, The method of claim 1, wherein, based on one or more curation tasks executed by the coder, the feedback processing module provides one or more feedbacks without user intervention, including:
an implicit feedback, based on the curation tasks including accepting, updating, and adding of actions, automatically collects the feedback; (Katwala, paragraphs 0106, 0112-0114, 0119, 0122)
Katwala teaches a workflow in which the coder’s ordinary accept, add, attach, and other code-related actions are captured as part of the system’s logged interaction history without requiring a separate feedback-submission step
and an explicit feedback, based on the curation task including deletion of an action, requires confirmation from the coder wherein
(Katwala, paragraphs 0106, 0119, 0122, 0113, 0114, 0040, 0042).
Katwala teach a deletion-type (adverse) human-curation workflow: each code suggestion can be accepted, rejected, or marked for review, and the user can add structured or free-text comments explaining that decision. Those actions are captured in an activity log that records changes to a patient’s medical codes.
However, Katwala does not teach adding a new rule based on consolidated feedback from the coder.
Swanson teaches adding a new rule based on consolidated coding feedback because Swanson receives medical coding feedback data, logs detected corrections, and modify or creates new medical record interpretation rules, including updating rules when the same feedback is obtained “X % of the time,” thereby improving subsequent medical-record and coding interpretation accuracy. Refer to Swanson Col. 5, ll. 43-55, Col. 8, ll.50-55, Col. 7, ll.1-15
A person of ordinary skill in the art would have combined Katwala with Swanson to improve Katwala’s proposed-code engine by learning from repeated coder outcomes rather than leaving coder actions as case-specific review results, consistent with Katwala’s rule-driven coding workflow ([0102], [0104]-[0106]) and Swanson’s teaching that feedback from coding systems is used to update the rules and modify or create new medical record interpretation rules for future processing (col. 5, ll. 44–60; col. 6, ll. 50–67; col. 8, ll. 38–52). By modifying Katwala so that repeated coder accept/reject/comment feedback is consolidated and used to add or revise its code-selection rules, the combined system would predictably improve later code suggestion accuracy, reduce repeated coding errors, and produce more reliable RAF-related recommendations.
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over US20180046764A1-Katwala and in view of US8612261 B1 - Swanson and further view of US 11,456,064 B2 - Mobarakeh.
Claim 10.
Katwala teaches, A system for calculating a risk adjustment factor (RAF), comprising one or more processors and one or more computer-readable storage devices having stored a plurality of computer-executable instructions, wherein execution of the computer-executable instructions causing the computer system to: (Katwala, paragraphs 0029–0031, 0104).
Katwala describes a computer system that uses natural language processing to extract health information from patient records and recommends risk adjustment codes through its user interface.
receive an input including a structured data and an unstructured data by a retrospective workflow to identify one or more clinical entities; (Katwala, paragraphs 0029–0030, fig. 1A,).
Katwala analyzes both structured and unstructured patient data using natural language processing to find medical information and supporting evidence in past records.
parse the unstructured data format into the structured data format by a Natural Language Processing (NLP) module that identifies clinical entities with attributes, status, and context and normalizes data based on specific use cases, and said parsed structured data and the input unstructured data is passed to an Application Recommendation System; (Katwala, paragraphs 0029–0031, 0034, 0036, 0050, 0102).
Katwala uses natural language processing to turn patient notes into structured data, then recommends medical codes to users through its interface.
identify an evidence by the Application Recommendation System based upon the unstructured data and said evidence is processed based on an input received from a master knowledge graph module that provides clinical context through a structured network of medical entities and relationships; (Katwala, paragraphs 0029–0031, 0034-0036, 0038-0039 0053, 0105, Fig. 1A).
Katwala, data engine identifies evidence from the unstructured documents and processed using the semantic taxonomy and clinical rules to output recommendations supported by references from the source documents.
suggest an output comprising ICD-10-CM codes, diagnosis evidence, by a prospective workflow to a coder, wherein the coder performs a plurality of curation tasks to provide a feedback to a feedback processing module; (Katwala, paragraphs 0031, 0104–0106; figure 9, , 0112-0113, 0120 fig. 20).
Katwala discloses presenting to a coder, within a prospective coding workflow, an output that includes ICD-10-CM codes, diagnosis evidence, MEAT review, HCC translation, and RAF impact, as shown by the proposed ICD-10 code and supporting evidence. Katwala also discloses the complete coder workflow because the coder performs multiple curation actions, accept, reject, or flag for further review, and those final decisions are recorded and later used by the system in subsequent recommendations.
and update the Application Recommendation System by adding a new rule therein and fine-tuning the risk adjustment workflow system , (Katwala, par. 0039-0042, 0104, 0030-0031, 0003, 0122, 0053, 0122)
The system allows the addition of new clinical rules by incorporating guidelines and associating them with concepts in the semantic taxonomy, and fine-tunes the risk adjustment factor (RAF) by dynamically updating it based on evidence from multiple documents to ensure accurate patient risk assessments.
wherein the retrospective workflow and the prospective workflow are
Under the broadest reasonable interpretation, this limitation requires at least two named, independently operable stack layers one retrospective and one prospective connected for shared data interoperability in medical code identification and validation, built on a reusable modular architecture that enables each layer to be deployed and commercialized as a standalone sub-solution.
Katwala teaches the stacked, connected processing layers and code identification function, as shown by "step 508 may involve three levels or categories of annotation that represent extracted entities...annotators are applied as a stack in which higher level annotators can operate on the results or benefit from the processing of lower-level annotators" and "a set of rules configured for selecting proposed medical codes based on patient documents for a particular patient, using data engine 106" (pars. [0059], [0102]). This reads on interconnected stack layers performing code identification because Katwala's annotator tiers process patient data in sequence while passing results downstream for code selection.
35 U.S.C 103 Obvious Rationales:
Katwala teaches all limitations above excepts, does not explicitly teach adding a new rule based on consolidated feedback from the coder and layers operating independently as separately commercializable modular sub-solutions.
adding a new rule based on consolidated feedback from the coder:
Swanson teaches adding a new rule based on consolidated coding feedback because Swanson receives medical coding feedback data, logs detected corrections, and modify or creates new medical record interpretation rules, including updating rules when the same feedback is obtained “X % of the time,” thereby improving subsequent medical-record and coding interpretation accuracy. Refer to Swanson Col. 5, ll. 43-55, Col. 8, ll.50-55, Col. 7, ll.1-15
A person of ordinary skill in the art would have combined Katwala with Swanson to improve Katwala’s proposed-code engine by learning from repeated coder outcomes rather than leaving coder actions as case-specific review results, consistent with Katwala’s rule-driven coding workflow ([0102], [0104]-[0106]) and Swanson’s teaching that feedback from coding systems is used to update the rules and modify or create new medical record interpretation rules for future processing (col. 5, ll. 44–60; col. 6, ll. 50–67; col. 8, ll. 38–52). By modifying Katwala so that repeated coder accept/reject/comment feedback is consolidated and used to add or revise its code-selection rules, the combined system would predictably improve later code suggestion accuracy, reduce repeated coding errors, and produce more reliable RAF-related recommendations.
layers operating independently as separately commercializable modular sub-solutions
Katwala discloses a stack of connected, interoperable annotator layers that pass processed results forward into medical-code selection based on patient documents. However, Katwala does not teach that these layers function independently as separately commercializable modular sub-solutions.
Mobarakeh discloses an open, modular healthcare architecture in which PCH ECO-system functional modules, including an Integrated EHR module with an HL7/FHIR engine and Open API access, can operate independently of each other. This teaches connected modules that remain interoperable through standard data interfaces. It also teaches separately commercializable sub-solutions because the independently operating modules within this open modular architecture are structurally capable of standalone deployment and reuse. Refer to Mobarakeh, Col. 5, ll. 10-67, Col. 6, ll. 12-40, fig 12-13
A person of ordinary skill in the art would have combined Katwala with Mobarakeh to implement Katwala’s retrospective analysis and prospective coding review as distinct interoperable modules within Mobarakeh’s modular healthcare platform. The modification would have used Mobarakeh’s “HL7 and FHIR engine” and “Open API” so Katwala’s stacked coding functions could exchange patient data across connected but independently operating modules, because Katwala seeks improved coding from multiple patient-data sources and Mobarakeh teaches an “open architecture” and modules that “operate independent of each other” (Katwala [0031], [0102]; Mobarakeh Col. 5, ll. 10-67, fig. 12-14). Doing so would have predictably yielded connected workflow layers that remain interoperable for code identification and validation while being reusable and capable of standalone deployment.
Conclusion
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 JOSHUA DAMIAN RUIZ whose telephone number is (571)272-0409. The examiner can normally be reached 0800-1800.
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, Shahid Merchant can be reached at (571) 270-1360. 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.
/JOSHUA DAMIAN RUIZ/Examiner, Art Unit 3684
/KAREN A HRANEK/Primary Examiner, Art Unit 3684
Prosecution Insights