Detailed Notice
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-16 are currently pending.
Claims 1-16 are amended.
Claims 17-18 are canceled.
Claims 1-16 are rejected.
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 therefore, subject to the conditions and requirements of this title.
Claims 1-16 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.
Step 1:
In the instant case, claims 1-14 are directed towards a computer-implemented method (i.e., process) and claims 14-16 are directed toward a system (i.e., machine). Thus, each of the claims falls within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A—Prong 1:
Independent claims 1 and 14 recites steps that, under their broadest reasonable interpretations, cover performance of the limitations of a certain method of organizing human activity but for the recitation of generic computer components.
Claim 1 recites: “A computer-implemented method for supporting the creation of a structured medical findings report comprising user-generated findings entries and a machine-readable hierarchical data structure, wherein at least one data structure element and a first ontology code encoding the findings entry are assigned to each findings entry by the computer, the computer-implemented method including steps comprising: a. on a user side, creating at least one findings entry within a reporting software environment; b. on a computer side, determining a case-specific parameter set based on existing data structure elements in such a way that predetermined data structure elements associated with the at least one findings entry are assigned to each parameters of the case-specific parameter set; c. on the computer side, assigning to the parameters of the case-specific parameter set parameter values stored in the assigned predetermined data structure elements; d. on the computer side, identify actions documented in previous structured medical finding reports, wherein the previous structured medical findings reports are stored in a findings report database and are determined within the findings report database using the case-specific parameter set and the parameter values and first ontology codes assigned to the at least one findings entry, as well as the information of an ontology database comprising the first and further ontology codes and systematic and factual relationships of the first and further ontology codes; e. on the computer side, generating an information overview comprising information about the actions as well as the parameters of the case-specific parameter set and the parameter values assigned to the parameters of the case-specific parameter set; and f. on the computer side, visualizing the information overview within the reporting software environment”.
The limitations of a. on a user side, creating at least one findings entry; b. determining a case-specific parameter set in such a way that predetermined data structure elements associated with the at least one findings entry are assigned to each parameters of the case-specific parameter set; c. assigning to the parameters of the case-specific parameter set parameter values; d. identify actions documented in previous structured medical finding reports, wherein the previous structured medical findings reports are determined using the case-specific parameter set and the parameter values and first ontology codes assigned to the at least one findings entry, as well as the information comprising the first and further ontology codes and systematic and factual relationships of the first and further ontology codes; e. generating an information overview comprising information about the actions as well as the parameters of the case-specific parameter set and the parameter values assigned to the parameters of the case-specific parameter set; and f. visualizing the information overview , given the broadest reasonable interpretation, cover the abstract idea of a certain method of organizing human activity because they recite managing personal behavior or relationships or interactions between people (i.e. social activities, teaching, and following rules or instructions—in this case the aforementioned steps recite a process of creating, determining, assigning, identify, generating, and visualizing, which is properly interpreted as a “personal behavior”), but instead automates the process via a computer model, e.g. see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements”, and will be discussed in further detail below.
Further, the abstract idea of claim 14 is identical as the abstract idea of claim 1. This limitation, given the broadest reasonable interpretation, also falls under the abstract idea of a certain method of organizing human activity because it recites managing personal behavior or relationships or interactions between people.
Dependent claims 2-13 and 15-16 include other limitations, as well as specific step of data to be processed, received, and applied, but these only serve to further limit the abstract idea and do not add and additional elements, and hence are nonetheless directed towards fundamentally the same abstract idea as independent claims 1 and 14. However, recitation of an abstract idea is not the end of the 35 U.S.C. 101 analysis. Each of the claims must be analyzed for additional elements that indicate the abstract idea is integrated into a practical application to determine whether the claim is considered to be “directed to” an abstract idea.
Step 2A—Prong 2:
Claims 1-16 are not integrated into a practical application because the additional elements (i.e. any limitations that are not identified as part of the abstract idea) amount to no more than limitations which:
Amount to mere instructions to apply an exception—for example, the recitation of “machine-readable hierarchical data structure”, “data structure”, “computer”, “reporting software environment”, “computer side”, “data structure elements”, “findings report database”, and “ontology database”, which amount to merely invoking a computer as a tool to perform the abstract idea, e.g. see FIG. 1, [0014]-[0015], and [0023], of the present specification, and see further MPEP 2106.05(f);
Generally linking the abstract idea to a particular technological environment or field of use, for example, “computer-implemented method for supporting the creation of a structured medical findings report comprising user-generated findings entries and a machine-readable hierarchical data structure, wherein at least one data structure element and a first ontology code encoding the findings entry are assigned to each findings entry by the computer, the computer-implemented method including steps comprising”, “creating at least one findings entry within a reporting software environment”, “on a computer side”, “based on existing data structure elements”, “on the computer side”, “stored in the assigned predetermined data structure elements”, “on the computer side”, “are stored in a findings report database and”, “within the findings report database”, “of an ontology database”, “on the computer side”, “on the computer side”, and “within the reporting software environment”, which amounts to limiting the abstract idea to the field of technology/the environment of computers, see MPEP 2106.05(h); and/or
Additionally, dependent claims 2-13 and 15-16 include other limitations, but as stated above, the limitations recited by these claims do not include any additional elements beyond those already recited in independent claims 1 and 14, and hence also do not integrate the aforementioned abstract idea into a practical application.
Step 2B:
The claims do not include additional elements that are sufficient to amount to “significantly more” than the judicial exception because the additional elements (i.e. the elements other than the abstract idea), as stated above, are directed towards no more than limitations that amount to mere instructions to apply the exception, and/or generally link the abstract idea to a particular technological environment or field of use, which even when reevaluated under the considerations of Step 2B of the analysis, do not amount to “significantly more” than the abstract idea.
Dependent claims 2-13 and 15-16 include other limitations, but none of these limitations are deemed significantly more than the abstract idea because, as stated above, the aforementioned dependent claims do not recite any additional elements not already recited in independent claims 1 and 14, and hence do not amount to “significantly more” than the abstract idea.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, claims 1-16 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.
Claim(s) 1-16 are rejected under 35 U.S.C. 103 as being unpatentable over Bhotika et al. (US 20160283657 A1), hereinafter Bhotika, in view Ozeran (US 20220319652 A1).
Regarding claim 1 Bhotika teaches a computer-implemented method for supporting the creation of a structured medical findings report comprising user-generated findings entries and a machine- readable hierarchical data structure, wherein at least one data structure element and a first ontology code encoding the findings entry are assigned to each findings entry by the computer (Bhotika, [0054] and [0056]), the computer-implemented method including steps comprising:
a. on a user side, creating at least one findings entry within a reporting software environment (Bhotika, [0012]: “a system providing a relatively complete offering for reporting, analysis and/or recommendations for further examination(s) may be provided to healthcare clinicians in which tools and/or data are embedded into the workflow. In some examples, the data embedded into the workflow includes imaging data, non-imaging data, results obtained based on imaging data analysis and/or non-imaging data analysis and/or other relevant findings related to the patient, another patient, study and/or data”, [0028], [0032], and [0055]: “data, recommendations, knowledge and/or analytics is performed on and/or obtained based on the structured data to provide assistance in connection with clinical reporting and/or decision support. In some examples, the clinical reporting includes a pre-draft structured clinical report, error checking, an update on disease progress, anomaly detection, etc. In some examples, the decision support includes calculating population statistics from the data (e.g., relevant archived data), correlating clinical information from different sources, find a reference case(s), etc.”);
b. on a computer side, determining a case-specific parameter set based on existing data structure elements in such a way that predetermined data structure elements associated with the at least one findings entry are assigned to each parameters of the case-specific parameter set (Bhotika, [0020]: “Additionally and/or alternatively, in some examples, the key findings identifier 118 identifies the parameter by reviewing contextual information of the current case and/or retrieved cases. Additionally and/or alternatively, in some examples, the key finding identifier 118 may identify one or more parameters (e.g., fields) included in the template”, [0021]: “In response to the parameters identified within, for example, a clinical report, the key findings identifier 118 searches for and/or identifies similar cases and/or external references related to the parameter. In some examples, the similar case(s) and/or the related reference(s) is displayed to the practitioner using the practitioner interface 114 and/or the similar case(s) and/or the related reference(s) is used by an analyzer 120 in connection with analyzing an image”, [0023], and [0028]: “the data sources 102, the data source receiver 110, the template generator 111, the data integration manager 112, the practitioner interface 114 and, more generally, one or more components of the healthcare environment 100 work together using case based retrieval and/or case based reasoning to assist in clinical decision support. In some examples, such case based retrieval and/or case based reasoning is used by the key findings identifier 118 to dynamically define parameters of interest using data relating to a current case and/or data relating to a previous case(s). Some parameters include, for example, prior imaging intensity information of the nodule, the location of the nodule and/or the shape of the nodule, etc. In some examples, such case based retrieval and/or case based reasoning is used by the analyzer 120 to dynamically define and/or label a region(s) of interest within an image and/or to determine a value(s) of a parameter(s). The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated”);
c. on the computer side, assigning to the parameters of the case-specific parameter set parameter values stored in the assigned predetermined data structure elements (Bhotika, [0020]: “Additionally and/or alternatively, in some examples, the key findings identifier 118 identifies the parameter by reviewing contextual information of the current case and/or retrieved cases. Additionally and/or alternatively, in some examples, the key finding identifier 118 may identify one or more parameters (e.g., fields) included in the template”, [0021]: “In response to the parameters identified within, for example, a clinical report, the key findings identifier 118 searches for and/or identifies similar cases and/or external references related to the parameter. In some examples, the similar case(s) and/or the related reference(s) is displayed to the practitioner using the practitioner interface 114 and/or the similar case(s) and/or the related reference(s) is used by an analyzer 120 in connection with analyzing an image”, [0023], and [0028]: “the data sources 102, the data source receiver 110, the template generator 111, the data integration manager 112, the practitioner interface 114 and, more generally, one or more components of the healthcare environment 100 work together using case based retrieval and/or case based reasoning to assist in clinical decision support. In some examples, such case based retrieval and/or case based reasoning is used by the key findings identifier 118 to dynamically define parameters of interest using data relating to a current case and/or data relating to a previous case(s). Some parameters include, for example, prior imaging intensity information of the nodule, the location of the nodule and/or the shape of the nodule, etc. In some examples, such case based retrieval and/or case based reasoning is used by the analyzer 120 to dynamically define and/or label a region(s) of interest within an image and/or to determine a value(s) of a parameter(s). The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated”);
e. on the computer side, generating an information overview comprising information about the actions as well as the parameters of the case-specific parameter set (Bhotika, [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated”, [0033]: “For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.). In some such examples, the data integration manager 112 and/or the practitioner interface 114 combines a GAIL model and image texture analysis from the analyzer 120 to determine a risk score to enable a practitioner to make a patient recommendation. In some examples, the patient recommendation includes recommending an additional imaging exam such as, for example, an ultrasound, a contrast enhanced mammogram, a magnetic resonance imaging (MRI), etc. In some such examples, to further improve the quality of a recommendation by the practitioner, the data integration manager 112 obtains a population plot including risk scores on which the patient's score is also included to enable a patient recommendation”) and the parameter values assigned to the parameters of the case-specific parameter set (Bhotika, [0043]: “The analyzer 120 determines a value of the parameter (block 712)” and [0044]: “The mapper 121 updates the clinical report based on the value of the parameter (block 714) by, for example, mapping the determined value to the clinical report and/or a template. In some examples, the output generator 114 automatically populates the clinical report and/or a template with the value determined by the analyzer 120. The mapper 122 maps the labeled image, the relevant findings and the updated clinical report to a model for further analysis and/or use in clinical decision support (block 716). In examples in which a breast density value is determined to be relatively high, in some examples, the analyzer 120 determines a parenchymal texture value and a distribution of fibroglandular tissue. In some examples, the values determined based on the analysis are used to determine a BI-RAD score and/or one or more recommendations based on the BI-RAD score”); and
f. on the computer side, visualizing the information overview within the reporting software environment (Bhotika, [0021]: “the similar case(s) and/or the related reference(s) is displayed to the practitioner using the practitioner interface 114 and/or the similar case(s) and/or the related reference(s) is used by an analyzer 120 in connection with analyzing an image”, [0034]: “In some examples, at block 224, the practitioner interface 114 displays, based on data obtained from the data integration manager 112, relevant patient information such as, for example, population based breast density and complexity analysis, breast cancer risk assessment based on clinical risk factors, outcome and recommendations from similar studies, a radiologic linked interpretation(s), a pathology linked interpretation(s), etc. Additionally, and/or alternatively, in some examples, at block 224, the practitioner interface 114 provides access to the electronic patient chart and/or other links to additional data such as, for example, breast documents, enhanced patient oriented report and/or primary study focus, etc., identified by the data integration manager 112”, and [0038]-[0039]).
Bhotika does not teach d. on the computer side, identify actions documented in previous structured medical finding reports, wherein the previous structured medical findings reports are stored in a findings report database and are determined within the findings report database using the case-specific parameter set and the parameter values and first ontology codes assigned to the at least one findings entry, as well as the information of an ontology database comprising the first and further ontology codes and systematic and factual relationships of the first and further ontology codes.
However, Ozeran teaches d. on the computer side, identify actions documented in previous structured medical finding reports (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, and [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”), wherein the previous structured medical findings reports are stored in a findings report database and are determined within the findings report database using the case-specific parameter set and the parameter values and first ontology codes assigned to the at least one findings entry (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”, [0277]: “an integration engine may receive a stream of XML and/or JSON content comprising structured data and corresponding ontological code systems and concepts as extracted from a health system's EMR at a single point in time”, [0303]: “Medical concepts can span numerous dictionaries, vocabularies and ontologies, and data elements within structured data generally conform to a specific system, concept code and preferred text descriptor”), as well as the information of an ontology database comprising the first and further ontology codes and systematic and factual relationships of the first and further ontology codes (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”, [0277]: “an integration engine may receive a stream of XML and/or JSON content comprising structured data and corresponding ontological code systems and concepts as extracted from a health system's EMR at a single point in time”, [0303]: “Medical concepts can span numerous dictionaries, vocabularies and ontologies, and data elements within structured data generally conform to a specific system, concept code and preferred text descriptor”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhotika to incorporate the teachings of Ozeran and account for obtaining and employing data related to patient characteristics, such as physical, clinical, or genomic characteristics, as well as diagnosis, treatments, and treatment efficacy to provide a suite of tools to healthcare providers, researchers, and other interested parties enabling those entities to develop new insights utilizing disease states, treatments, results, genomic information and other clinical information to improve overall patient healthcare (Ozeran. Abstract and [0003]).
Regarding claim 2 Bhotika teaches on the user side, modifying the case-specific parameter set and/or the parameter values assigned to the parameters of the case-specific parameter set to create a modified case-specific parameter set, (Bhotika, [0020]-[0021], [0023]: “the analyzer 120 reviews past studies, publications and/or guidelines and/or data related to the current case and/or retrieved cases to more accurately identify different aspects of the image and/or determine different parameter values associated with the image”, [0028]: “the data sources 102, the data source receiver 110, the template generator 111, the data integration manager 112, the practitioner interface 114 and, more generally, one or more components of the healthcare environment 100 work together using case based retrieval and/or case based reasoning to assist in clinical decision support. In some examples, such case based retrieval and/or case based reasoning is used by the key findings identifier 118 to dynamically define parameters of interest using data relating to a current case and/or data relating to a previous case(s). Some parameters include, for example, prior imaging intensity information of the nodule, the location of the nodule and/or the shape of the nodule, etc. In some examples, such case based retrieval and/or case based reasoning is used by the analyzer 120 to dynamically define and/or label a region(s) of interest within an image and/or to determine a value(s) of a parameter(s)”, [0057]: “to enable decision support, the examples disclosed herein use example retrieval processes to retrieve similar historical cases (e.g., images and reports) and/or external publications. In some examples, based on the relevance and/or the context of the retrieved data, the examples disclosed herein display a “snapshot” view and/or a brief summary to a practitioner to enable the practitioner to efficiently browse through the retrieved data to identify and/or obtain the information and/or relevant data from the retrieved results. Using the examples disclosed herein and/or the retrieved and/or determined data, practitioners can obtain suggested diagnoses and/or perform expert-guided image analytics. In some examples, the image analytics include key anatomical feature labeling, segmentation, automatic measurements, etc. to enable clinical decision support and/or decision making. In some examples, structurally representing imaging and/or non-imaging data and/or providing links between the imaging and/or non-imaging data enables analytics to be performed”), and on the computer side repeating steps e) using the modified case-specific parameter set and the parameter values assigned to the modified case-specific parameter set (Bhotika, [0020]-[0021], [0023]: “the analyzer 120 reviews past studies, publications and/or guidelines and/or data related to the current case and/or retrieved cases to more accurately identify different aspects of the image and/or determine different parameter values associated with the image”, [0028]: “the data sources 102, the data source receiver 110, the template generator 111, the data integration manager 112, the practitioner interface 114 and, more generally, one or more components of the healthcare environment 100 work together using case based retrieval and/or case based reasoning to assist in clinical decision support. In some examples, such case based retrieval and/or case based reasoning is used by the key findings identifier 118 to dynamically define parameters of interest using data relating to a current case and/or data relating to a previous case(s). Some parameters include, for example, prior imaging intensity information of the nodule, the location of the nodule and/or the shape of the nodule, etc. In some examples, such case based retrieval and/or case based reasoning is used by the analyzer 120 to dynamically define and/or label a region(s) of interest within an image and/or to determine a value(s) of a parameter(s)”, [0057]: “to enable decision support, the examples disclosed herein use example retrieval processes to retrieve similar historical cases (e.g., images and reports) and/or external publications. In some examples, based on the relevance and/or the context of the retrieved data, the examples disclosed herein display a “snapshot” view and/or a brief summary to a practitioner to enable the practitioner to efficiently browse through the retrieved data to identify and/or obtain the information and/or relevant data from the retrieved results. Using the examples disclosed herein and/or the retrieved and/or determined data, practitioners can obtain suggested diagnoses and/or perform expert-guided image analytics. In some examples, the image analytics include key anatomical feature labeling, segmentation, automatic measurements, etc. to enable clinical decision support and/or decision making. In some examples, structurally representing imaging and/or non-imaging data and/or providing links between the imaging and/or non-imaging data enables analytics to be performed”).
However, Bhotika does not teach repeating steps d).
However, Ozeran teaches repeating steps d) (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”, [0277]: “an integration engine may receive a stream of XML and/or JSON content comprising structured data and corresponding ontological code systems and concepts as extracted from a health system's EMR at a single point in time”, [0303]: “Medical concepts can span numerous dictionaries, vocabularies and ontologies, and data elements within structured data generally conform to a specific system, concept code and preferred text descriptor”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhotika to incorporate the teachings of Ozeran and account for obtaining and employing data related to patient characteristics, such as physical, clinical, or genomic characteristics, as well as diagnosis, treatments, and treatment efficacy to provide a suite of tools to healthcare providers, researchers, and other interested parties enabling those entities to develop new insights utilizing disease states, treatments, results, genomic information and other clinical information to improve overall patient healthcare (Ozeran. Abstract and [0003]).
Regarding claim 3 Bhotika further teaches generating a structured medical findings report comprising documentation of at least one action, and adding the structured medical findings report to the findings report database (Bhotika, [0033]: ‘Block 222 can be implemented by the data integration manager 112. In some examples, the data integration manager 112 performs analytics on the structured data to provide a recommendation(s) to a practitioner. For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.)” and [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated. In some examples, the output is used to determine breast density and parenchymal texture. In some examples, based on the processing disclosed herein such as, for example, a determined Breast Imaging Reporting and Data System (BI-RADS) score determined using the examples disclosed herein, a recommendation on a next action(s) can be made”).
Regarding claim 4 Bhotika further teaches generating, on the computer side, statistical information on individual identified actions documented in the findings report database (Bhotika, [0055]: “In some examples, data, recommendations, knowledge and/or analytics is performed on and/or obtained based on the structured data to provide assistance in connection with clinical reporting and/or decision support. In some examples, the clinical reporting includes a pre-draft structured clinical report, error checking, an update on disease progress, anomaly detection, etc. In some examples, the decision support includes calculating population statistics from the data (e.g., relevant archived data), correlating clinical information from different sources, find a reference case(s), etc.”); and adding the statistical information to the information overview (Bhotika, [0055]: “In some examples, data, recommendations, knowledge and/or analytics is performed on and/or obtained based on the structured data to provide assistance in connection with clinical reporting and/or decision support. In some examples, the clinical reporting includes a pre-draft structured clinical report, error checking, an update on disease progress, anomaly detection, etc. In some examples, the decision support includes calculating population statistics from the data (e.g., relevant archived data), correlating clinical information from different sources, find a reference case(s), etc.”).
Regarding claim 5 Bhotika further teaches the statistical information on the individual identified actions comprises at least one count statistic of the occurrence of individual identified actions in the findings report database (Bhotika, [0055]: “In some examples, data, recommendations, knowledge and/or analytics is performed on and/or obtained based on the structured data to provide assistance in connection with clinical reporting and/or decision support. In some examples, the clinical reporting includes a pre-draft structured clinical report, error checking, an update on disease progress, anomaly detection, etc. In some examples, the decision support includes calculating population statistics from the data (e.g., relevant archived data), correlating clinical information from different sources, find a reference case(s), etc.” and [0056]).
Regarding claim 6 Bhotika further teaches in which the identified actions comprise suggestions and/or instructions for actions and/or findings (Bhotika, [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated. In some examples, the output is used to determine breast density, parenchymal texture. In some examples, based on the processing disclosed herein such as, for example, a determined Breast Imaging Reporting and Data System (BI-RADS) score determined using the examples disclosed herein, a recommendation on a next action(s) can be made” and [0033]: “Block 222 can be implemented by the data integration manager 112. In some examples, the data integration manager 112 performs analytics on the structured data to provide a recommendation(s) to a practitioner. For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.)”) and, in particular therapy suggestions, suggestions for further diagnostic measures and/or suggestions for further findings (Bhotika, [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated. In some examples, the output is used to determine breast density, parenchymal texture. In some examples, based on the processing disclosed herein such as, for example, a determined Breast Imaging Reporting and Data System (BI-RADS) score determined using the examples disclosed herein, a recommendation on a next action(s) can be made” and [0033]: “Block 222 can be implemented by the data integration manager 112. In some examples, the data integration manager 112 performs analytics on the structured data to provide a recommendation(s) to a practitioner. For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.)”).
Regarding claim 7 Bhotika further teaches on the computer side, based on data contained in at least one patient-outcome database, generating information about clinical outcomes attributable to the identified actions (Bhotika, [0034]: “Block 224 can be implemented by the practitioner interface 114 using data obtained from block 214, the data source retriever 102 and/or the data integration manager 112. In some examples, at block 224, the practitioner interface 114 displays, based on data obtained from the data integration manager 112, relevant patient information such as, for example, population based breast density and complexity analysis, breast cancer risk assessment based on clinical risk factors, outcome and recommendations from similar studies, a radiologic linked interpretation(s), a pathology linked interpretation(s), etc.”); and adding the information about clinical outcomes attributable to the identified actions to the information overview (Bhotika, [0009]: “the imaging and/or non-imaging data and any corresponding analysis results are indexed and/or mapped based on standard medical terms (e.g., common medical language) to enable, for example and among other things, collaboration between different specialists”).
Regarding claim 8 Bhotika further teaches the information about clinical outcomes comprises statistical information (Bhotika, [0055]: “In some examples, data, recommendations, knowledge and/or analytics is performed on and/or obtained based on the structured data to provide assistance in connection with clinical reporting and/or decision support. In some examples, the clinical reporting includes a pre-draft structured clinical report, error checking, an update on disease progress, anomaly detection, etc. In some examples, the decision support includes calculating population statistics from the data (e.g., relevant archived data), correlating clinical information from different sources, find a reference case(s), etc.”).
Regarding claim 9 Bhotika does not teach determining that a user-documented action in the findings report deviates from being a most frequently documented action and/or an action having a greatest likelihood of achieving a desired clinical outcome: receiving a decision rationale for the user-documented action deviating from being the most frequently documented action and/or the action having a greatest likelihood of achieving a desired clinical outcome; and saving the decision rationale.
However, Ozeran teaches determining that a user-documented action in the findings report deviates from being a most frequently documented action and/or an action having a greatest likelihood of achieving a desired clinical outcome (Ozeran, [0339]: “The system then may search for similarities in clinical data among those other patients in order to develop a template test suite. Thus, the system may assume that the other patients' clinical data is accurate, such that deviations from that data when a validation check is performed on a subject patient's data may trigger an alert to the provider or reviewer as to either an error in the subject patient's data or, alternatively, to an unexpected result that may warrant further investigation”): receiving a decision rationale for the user-documented action deviating from being the most frequently documented action and/or the action having a greatest likelihood of achieving a desired clinical outcome; and saving the decision rationale (Ozeran, [0340]-[)341]: “In still another example, the system may rely on data from other patients to determine whether the data in a target patient's record appears correct or whether it may warrant an alert signifying a potential error or an otherwise unexpected finding. For example, a patient record may include both clinical and molecular data, where the molecular data may include data reflecting a “new” gene, in that there may not be much, if any, clinical knowledge regarding the medical effects of having the gene. In that case, the system may search its data store for indications of other patients with that gene. The system then may search for similarities in clinical data among those other patients in order to develop a template test suite. Thus, the system may assume that the other patients' clinical data is accurate, such that deviations from that data when a validation check is performed on a subject patient's data may trigger an alert to the provider or reviewer as to either an error in the subject patient's data or, alternatively, to an unexpected result that may warrant further investigation”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhotika to incorporate the teachings of Ozeran and account for obtaining and employing data related to patient characteristics, such as physical, clinical, or genomic characteristics, as well as diagnosis, treatments, and treatment efficacy to provide a suite of tools to healthcare providers, researchers, and other interested parties enabling those entities to develop new insights utilizing disease states, treatments, results, genomic information and other clinical information to improve overall patient healthcare (Ozeran. Abstract and [0003]).
Regarding claim 10 Bhotika further teaches in which a model for generating suggestions for actions is trained using the findings report database (Bhotika, [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated. In some examples, the output is used to determine breast density, parenchymal texture. In some examples, based on the processing disclosed herein such as, for example, a determined Breast Imaging Reporting and Data System (BI-RADS) score determined using the examples disclosed herein, a recommendation on a next action(s) can be made” and [0033]: “Block 222 can be implemented by the data integration manager 112. In some examples, the data integration manager 112 performs analytics on the structured data to provide a recommendation(s) to a practitioner. For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.)”).
Regarding claim 11 Bhotika further teaches in which a model for generating suggestions for actions is trained using the findings report database and the decision rationale (Bhotika, [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated. In some examples, the output is used to determine breast density, parenchymal texture. In some examples, based on the processing disclosed herein such as, for example, a determined Breast Imaging Reporting and Data System (BI-RADS) score determined using the examples disclosed herein, a recommendation on a next action(s) can be made” and [0033]: “Block 222 can be implemented by the data integration manager 112. In some examples, the data integration manager 112 performs analytics on the structured data to provide a recommendation(s) to a practitioner. For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.)”).
Regarding claim 12 Bhotika further teaches in which the case-specific parameter set used in the creation of the findings report is stored (Bhotika, [0032]: “the data integration manager 112 leverages digital imaging and communications in medical (DICOM) enhanced structured reporting (SR) service-object pair (SOP)class and/or plain text SR SOP class to store, query and/or retrieve the data (e.g., results of analysis, data analyzed, related findings, data, etc.). In some examples, the data integration manager 112 enables the generation of a structured and/or coded report and/or findings 220 by parsing clinical information into a structured form and/or using the parsed data to extract relevant information” and [0042]: “the key findings identifier 118 reviews and/or parses through cases stored in a database to identify one or more similar cases based on the identified parameter, symptoms of the patient, the patient history, the patient information, etc. The similar cases may be related to the patient or another individual”).
Regarding claim 13 Bhotika further teaches in which a model for generating parameter sets is trained on the basis of case-specific parameter sets stored as part of creation of the previous findings reports (Bhotika, [0032]: “the data integration manager 112 leverages digital imaging and communications in medical (DICOM) enhanced structured reporting (SR) service-object pair (SOP)class and/or plain text SR SOP class to store, query and/or retrieve the data (e.g., results of analysis, data analyzed, related findings, data, etc.). In some examples, the data integration manager 112 enables the generation of a structured and/or coded report and/or findings 220 by parsing clinical information into a structured form and/or using the parsed data to extract relevant information” and [0042]: “the key findings identifier 118 reviews and/or parses through cases stored in a database to identify one or more similar cases based on the identified parameter, symptoms of the patient, the patient history, the patient information, etc. The similar cases may be related to the patient or another individual”).
Regarding claim 14 Bhotika teaches a computer system for supporting the creation of a structured medical findings report comprising user-generated findings entries and a machine-readable hierarchical data structure, wherein at least one data structure element and a first ontology code encoding the findings entry are assigned to each findings entry by the computer, the computer system comprising (Bhotika, [0054] and [0056]): at least one memory having stored thereon (Bhotika, [0041]: “As mentioned above, the example processes of FIG. 7 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information)”): a findings report database comprising a plurality of structured findings reports comprising the documentation of at least one action (Bhotika, [0035]: “In some examples, based on the extracted information from current exam images (lesion size, shape, etc.) and key information from medical recordings, the examples disclosed herein can search the other resources (e.g., the internet, an internal database, an external database) to obtain additional case relevant information” and [0042]: “The key findings identifier 118 searches for and/or reviews other data to identify relevant findings based on the parameter (block 706). For example, the key findings identifier 118 reviews and/or parses through cases stored in a database to identify one or more similar cases based on the identified parameter, symptoms of the patient, the patient history, the patient information, etc. The similar cases may be related to the patient or another individual”); and a processing unit configured to access the at least one memory and carry out steps comprising (Bhotika, [0041]: “As mentioned above, the example processes of FIG. 7 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information)”): a. on a user side, creating at least one findings entry within a reporting software environment (Bhotika, [0012]: “a system providing a relatively complete offering for reporting, analysis and/or recommendations for further examination(s) may be provided to healthcare clinicians in which tools and/or data are embedded into the workflow. In some examples, the data embedded into the workflow includes imaging data, non-imaging data, results obtained based on imaging data analysis and/or non-imaging data analysis and/or other relevant findings related to the patient, another patient, study and/or data”, [0028], [0032], and [0055]: “data, recommendations, knowledge and/or analytics is performed on and/or obtained based on the structured data to provide assistance in connection with clinical reporting and/or decision support. In some examples, the clinical reporting includes a pre-draft structured clinical report, error checking, an update on disease progress, anomaly detection, etc. In some examples, the decision support includes calculating population statistics from the data (e.g., relevant archived data), correlating clinical information from different sources, find a reference case(s), etc.”); b. on a computer side, determining a case-specific parameter set based on existing data structure elements in such a way that predetermined data structure elements associated with the at least one findings entry are assigned to each parameter of the case- specific parameter set (Bhotika, [0020]: “Additionally and/or alternatively, in some examples, the key findings identifier 118 identifies the parameter by reviewing contextual information of the current case and/or retrieved cases. Additionally and/or alternatively, in some examples, the key finding identifier 118 may identify one or more parameters (e.g., fields) included in the template”, [0021]: “In response to the parameters identified within, for example, a clinical report, the key findings identifier 118 searches for and/or identifies similar cases and/or external references related to the parameter. In some examples, the similar case(s) and/or the related reference(s) is displayed to the practitioner using the practitioner interface 114 and/or the similar case(s) and/or the related reference(s) is used by an analyzer 120 in connection with analyzing an image”, [0023], and [0028]: “the data sources 102, the data source receiver 110, the template generator 111, the data integration manager 112, the practitioner interface 114 and, more generally, one or more components of the healthcare environment 100 work together using case based retrieval and/or case based reasoning to assist in clinical decision support. In some examples, such case based retrieval and/or case based reasoning is used by the key findings identifier 118 to dynamically define parameters of interest using data relating to a current case and/or data relating to a previous case(s). Some parameters include, for example, prior imaging intensity information of the nodule, the location of the nodule and/or the shape of the nodule, etc. In some examples, such case based retrieval and/or case based reasoning is used by the analyzer 120 to dynamically define and/or label a region(s) of interest within an image and/or to determine a value(s) of a parameter(s). The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated”); c. on the computer side, assigning to the parameters of the case-specific parameter set parameter values stored in the assigned predetermined data structure elements (Bhotika, [0020]: “Additionally and/or alternatively, in some examples, the key findings identifier 118 identifies the parameter by reviewing contextual information of the current case and/or retrieved cases. Additionally and/or alternatively, in some examples, the key finding identifier 118 may identify one or more parameters (e.g., fields) included in the template”, [0021]: “In response to the parameters identified within, for example, a clinical report, the key findings identifier 118 searches for and/or identifies similar cases and/or external references related to the parameter. In some examples, the similar case(s) and/or the related reference(s) is displayed to the practitioner using the practitioner interface 114 and/or the similar case(s) and/or the related reference(s) is used by an analyzer 120 in connection with analyzing an image”, [0023], and [0028]: “the data sources 102, the data source receiver 110, the template generator 111, the data integration manager 112, the practitioner interface 114 and, more generally, one or more components of the healthcare environment 100 work together using case based retrieval and/or case based reasoning to assist in clinical decision support. In some examples, such case based retrieval and/or case based reasoning is used by the key findings identifier 118 to dynamically define parameters of interest using data relating to a current case and/or data relating to a previous case(s). Some parameters include, for example, prior imaging intensity information of the nodule, the location of the nodule and/or the shape of the nodule, etc. In some examples, such case based retrieval and/or case based reasoning is used by the analyzer 120 to dynamically define and/or label a region(s) of interest within an image and/or to determine a value(s) of a parameter(s). The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated”); e. on the computer side, generating an information overview comprising information about the actions as well as the parameters of the case-specific parameter set (Bhotkia, [0028]: “The data obtained and/or generated by the components of the healthcare environment 100 reduce the workload on a practitioner by increasing workflow efficiency and/or providing actionable information within the report generated”, [0033]: “For example, in some examples, the data integration manager 112 combines a model and image analysis data from the analyzer 120 to provide a recommendation on a next action to be taken (e.g., another procedure, another exam, etc.). In some such examples, the data integration manager 112 and/or the practitioner interface 114 combines a GAIL model and image texture analysis from the analyzer 120 to determine a risk score to enable a practitioner to make a patient recommendation. In some examples, the patient recommendation includes recommending an additional imaging exam such as, for example, an ultrasound, a contrast enhanced mammogram, a magnetic resonance imaging (MRI), etc. In some such examples, to further improve the quality of a recommendation by the practitioner, the data integration manager 112 obtains a population plot including risk scores on which the patient's score is also included to enable a patient recommendation”) and the parameter values assigned to the parameters of the case-specific parameter set (Bhotika, [0043]: “The analyzer 120 determines a value of the parameter (block 712)” and [0044]: “The mapper 121 updates the clinical report based on the value of the parameter (block 714) by, for example, mapping the determined value to the clinical report and/or a template. In some examples, the output generator 114 automatically populates the clinical report and/or a template with the value determined by the analyzer 120. The mapper 122 maps the labeled image, the relevant findings and the updated clinical report to a model for further analysis and/or use in clinical decision support (block 716). In examples in which a breast density value is determined to be relatively high, in some examples, the analyzer 120 determines a parenchymal texture value and a distribution of fibroglandular tissue. In some examples, the values determined based on the analysis are used to determine a BI-RAD score and/or one or more recommendations based on the BI-RAD score”); and f. on the computer side, visualizing the information overview within the reporting software environment (Bhotika, [0021]: “the similar case(s) and/or the related reference(s) is displayed to the practitioner using the practitioner interface 114 and/or the similar case(s) and/or the related reference(s) is used by an analyzer 120 in connection with analyzing an image”, [0034]: “In some examples, at block 224, the practitioner interface 114 displays, based on data obtained from the data integration manager 112, relevant patient information such as, for example, population based breast density and complexity analysis, breast cancer risk assessment based on clinical risk factors, outcome and recommendations from similar studies, a radiologic linked interpretation(s), a pathology linked interpretation(s), etc. Additionally and/or alternatively, in some examples, at block 224, the practitioner interface 114 provides access to the electronic patient chart and/or other links to additional data such as, for example, breast documents, enhanced patient oriented report and/or primary study focus, etc., identified by the data integration manager 112”, and [0038]-[0039]).
Bhotika does not teach d. on the computer side, identifying actions documented in previous structured medical finding reports, wherein the previous structured medical findings reports are stored in a findings report database and are determined within the findings report database using the case-specific parameter set and the parameter values and first ontology codes assigned to the at least one findings entry, as well as the information of an ontology database comprising the first and further ontology codes and systematic and factual relationships of the first and further ontology codes.
However, Ozeran teaches d. on the computer side, identifying actions documented in previous structured medical finding reports (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, and [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”), wherein the previous structured medical findings reports are stored in a findings report database and are determined within the findings report database using the case-specific parameter set and the parameter values and first ontology codes assigned to the at least one findings entry (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”, [0277]: “an integration engine may receive a stream of XML and/or JSON content comprising structured data and corresponding ontological code systems and concepts as extracted from a health system's EMR at a single point in time”, [0303]: “Medical concepts can span numerous dictionaries, vocabularies and ontologies, and data elements within structured data generally conform to a specific system, concept code and preferred text descriptor”), as well as the information of an ontology database comprising the first and further ontology codes and systematic and factual relationships of the first and further ontology codes (Ozeran, [0031]: “Rich and meaningful data can be found in source clinical documents and records, such as diagnosis, progress notes, pathology reports, radiology reports, lab test results, follow-up notes, images, and flow sheets. These types of records are referred to as “raw clinical data”. However, many electronic health records do not include robust structured data fields that permit storage of clinical data in a structured format. Where electronic medical record systems capture clinical data in a structured format, they do so with a primary focus on data fields required for billing operations or compliance with regulatory requirements”, [0163]: “A knowledge database may be generated for accumulating a cohort of patient NGS results and clinical information. The accumulated patient information may be analyzed to identify insights such as potential biomarkers or trends in pharmacogenomics”, [0178]: “Analytics module 146 can, in general, use available data to indicate a diagnosis, predict progression, predict treatment outcomes, and/or suggest an optimized treatment plan (such as a medication type, an available clinical trial) based on the specific disease state of each patient”, [0270]: “In a third aspect, patient data may be Electronic Medical Record (EMR)-extracted structured data. This data can include a set of text strings representing various clinical attributes but may also include various ontological code systems and concepts to represent each text string in a way that can be compared against other data sets and/or validations. As a result of this structuring, the data mapping exercise may be significantly more straightforward than the exercise required for either of the other two instances”, [0277]: “an integration engine may receive a stream of XML and/or JSON content comprising structured data and corresponding ontological code systems and concepts as extracted from a health system's EMR at a single point in time”, [0303]: “Medical concepts can span numerous dictionaries, vocabularies and ontologies, and data elements within structured data generally conform to a specific system, concept code and preferred text descriptor”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhotika to incorporate the teachings of Ozeran and account for obtaining and employing data related to patient characteristics, such as physical, clinical, or genomic characteristics, as well as diagnosis, treatments, and treatment efficacy to provide a suite of tools to healthcare providers, researchers, and other interested parties enabling those entities to develop new insights utilizing disease states, treatments, results, genomic information and other clinical information to improve overall patient healthcare (Ozeran. Abstract and [0003]).
Regarding claim 15 Bhotika further teaches the at least one memory further has(Bhotika, [0035]: “the input includes medical records associated with the case. In some examples, based on the extracted information from current exam images (lesion size, shape, etc.) and key information from medical recordings, the examples disclosed herein can search the other resources (e.g., the internet, an internal database, an external database) to obtain additional case relevant information” and [0042]: “The process of FIG. 7 begins at block 702 with the key findings identifier 118 reviewing a clinical report associated with an image (block 702). The key findings identifier 118 reviews the clinical report to identify a parameter (e.g., parameter of interest) within the report (block 704). In some examples, the parameter is dynamically identified by the key findings identifier 118 by comparing one or more words or phrases within the clinical report to a reference list of parameters. Some parameters may include breast density, breast texture, breast lesion, etc. However, different parameters may be identified based on the patient, the modality, etc. The key findings identifier 118 searches for and/or reviews other data to identify relevant findings based on the parameter (block 706). For example, the key findings identifier 118 reviews and/or parses through cases stored in a database to identify one or more similar cases based on the identified parameter, symptoms of the patient, the patient history, the patient information, etc.”).
Regarding claim 16 Bhotika further teaches the findings report database comprises the at least one patient-outcome database ([0034]-[0035]: “Block 224 can be implemented by the practitioner interface 114 using data obtained from block 214, the data source retriever 102 and/or the data integration manager 112. In some examples, at block 224, the practitioner interface 114 displays, based on data obtained from the data integration manager 112, relevant patient information such as, for example, population based breast density and complexity analysis, breast cancer risk assessment based on clinical risk factors, outcome and recommendations from similar studies, a radiologic linked interpretation(s), a pathology linked interpretation(s), etc. Additionally and/or alternatively, in some examples, at block 224, the practitioner interface 114 provides access to the electronic patient chart and/or other links to additional data such as, for example, breast documents, enhanced patient oriented report and/or primary study focus, etc., identified by the data integration manager 112… FIGS. 3-6 are example user interfaces 300, 400, 500 and 600 that can be used to implement the practitioner interface 114 and/or the one or more components of the healthcare environment 100. Referring to the user interface 300 of FIG. 3, a case images tab 302 is selected and a first portion 304, a second portion 304 and a third portion 306 of the user interface 300 is shown. In some examples, the inputs include current exam images(s), the purpose of the exam and/or the exam type. In some examples, the input includes medical records associated with the case. In some examples, based on the extracted information from current exam images (lesion size, shape, etc.) and key information from medical recordings, the examples disclosed herein can search the other resources (e.g., the internet, an internal database, an external database) to obtain additional case relevant information” and [0042]: “For example, the key findings identifier 118 reviews and/or parses through cases stored in a database to identify one or more similar cases based on the identified parameter, symptoms of the patient, the patient history, the patient information, etc. The similar cases may be related to the patient or another individual”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHAEL SOJIN STONE whose telephone number is (571)272-8798. The examiner can normally be reached Monday-Friday 7 AM - 7 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Peter Choi can be reached at (469) 295-9171. 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.
/R.S.S./Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
