DETAILED CORRESPONDANCE
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of claims
This final office action on merits is in response to the communication received on 05/18/2026. Claims 2, 5, and 7 are cancelled. Amendments to claims 1, 3-4, 6, and 11-13 are acknowledged and have been carefully considered. Claims 1, 3-4, 6, and 8-13 are pending and considered below.
Drawings
In view of Applicant’s submission of compliant replacement drawing sheet(s), the objection to the drawings is withdrawn.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-4, 6, and 8-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1, 3-4, and 11-13 are drawn to a method, claims 6, and 8-10 are drawn to a system. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claims 4 and 6 recite the limitations of searching a database of a medical institution with search words; extracting patients who have undergone the standard treatment in the past as targets; and selecting eligible persons from the targets (claim 4), and search words converted from eligibility conditions and exclusion conditions of clinical trial information are accumulated in the clinical trial database, the accumulated patient information is searched with the search words, a matching patient can be extracted (claim 6). These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover performance of the limitations in the mind or by using a pen and paper. Even when considering the “wherein data is stored in the database as structured data” or “the patient information is accumulated in the server computer as structured data” language, the claims encompass a user reviewing patient information, comparing the patient information to search words representing patients who have undergone standard treatment, and selecting eligible persons from the identified patients (claim 4) and reviewing patient information, comparing the patient information to search words representing eligibility and exclusion conditions of a clinical trial, and identifying matching patients (claim 6) in their mind or by using a pen and paper. The mere nominal recitations of a database or a server computer do not take the claim limitations out of the mental processes grouping. Thus, the claims recite a mental process which is an abstract idea.
Independent claim 1 recites identical or nearly identical steps with respect to claim 4 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this claim is therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per claim 4, include:
searching a database of a medical institution with search words;
extracting patients who have undergone the standard treatment in the past as targets; and
selecting eligible persons from the targets,
wherein data is stored in the database as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule.
The claimed limitations, as per claim 6, include:
a server computer in which patient information is accumulated;
an electronic health record system including a data warehouse;
a terminal to which the patient information is input from each diagnosis and treatment department; and
a clinical trial database of a medical institution,
wherein the patient information input from the electronic health record system and the terminal at each diagnosis and treatment department is accumulated in the server computer,
search words converted from eligibility conditions and exclusion conditions of clinical trial information are accumulated in the clinical trial database,
the accumulated patient information is searched with the search words,
a matching patient can be extracted, and
the patient information is accumulated in the server computer as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claims 4 and 6 are not integrated into a practical application. The claims as a whole merely describe how to generally “apply” the concepts of reviewing patient information, comparing the patient information to search words representing patients who have undergone standard treatment, and selecting eligible persons from the identified patients (claim 4) and reviewing patient information, comparing the patient information to search words representing eligibility and exclusion conditions of a clinical trial, and identifying matching patients (claim 6) in a computer environment. The claimed computer components (i.e., wherein data is stored in the database as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule (claim 4) and server computer in which patient information is accumulated; an electronic health record system including a data warehouse; a clinical trial database of a medical institution; and the patient information is accumulated in the server computer as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule (claim 6)) are recited at a high level of generality and are merely invoked as tools to perform an existing process of reviewing patient information, comparing the patient information to predetermined eligibility criteria, and identifying or selecting patients satisfying those criteria. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 6 is not integrated into a practical application. The claim recites the additional elements of a terminal to which the patient information is input from each diagnosis and treatment department and wherein the patient information input from the electronic health record system and the terminal at each diagnosis and treatment department is accumulated in the server computer. These limitations are recited at a high level of generality (i.e., as a general means of receiving or collecting patient information for subsequent evaluation), and amount to merely data gathering, which is a form of insignificant extra-solution activity. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claims 4 and 6 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concepts of reviewing patient information, comparing the patient information to search words representing patients who have undergone standard treatment, and selecting eligible persons from the identified patients (claim 4) and reviewing patient information, comparing the patient information to search words representing eligibility and exclusion conditions of a clinical trial, and identifying matching patients (claim 6) in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
For claim 6, under step 2B, the additional elements of terminal to which the patient information is input from each diagnosis and treatment department and wherein the patient information input from the electronic health record system and the terminal at each diagnosis and treatment department is accumulated in the server computer have been evaluated. As noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for subsequent analysis without a technological improvement does not add significantly more to an abstract idea. The use of the method and system are no more than collecting information before reviewing patient information, comparing the patient information to eligibility and exclusion criteria represented by search words, and identifying matching patients, and such generic data gathering does not integrate the abstract idea into a practical application. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 3, and 9-13 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claim 8 recites the additional element of a server storage unit (claim 8). However, this additional element amounts to implementing an abstract idea on a generic computing device. As such, this additional element, when considered individually or in combination with the previously identified additional elements, does not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claims are rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 102
In light of Applicant’s amendment and arguments, the rejection of the claims under 35 U.S.C. 102 is withdrawn, however, new grounds of rejections under 35 U.S.C. 103 has been provided below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 6, and 8-13 are rejected under 35 U.S.C. 103 as being unpatentable over Kahn et al. (U.S. Patent Publication 2014/0249845A1), referred to hereinafter as Kahn, in view of Ozeran et al. (U.S. Patent Publication 2020/0381087A1), referred to hereinafter as Ozeran.
Regarding claim 1, Kahn teaches a clinical trial candidate screening method for screening candidates for a clinical trial, the clinical trial candidate screening method comprising (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”); and
extracting eligible persons (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”).
Kahn fails to explicitly teach searching a database of a medical institution with search words; and wherein data is stored in the database as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule.
Ozeran teaches searching a database of a medical institution with search words (Ozeran [0249] “In some embodiments, the flow 3200 can include matching the patient with one or more clinical trials using the patient data store 3202. The patient data store 3202 can provide a number of different features as described above. The FDA requires clinical trials to register before they may enroll patients and be held. In some embodiments, the flow 3200 can include accessing registered clinical trials at one or more websites 3262, such as clinicaltrials.gov, which contains a complete listing of all clinical trials registered with the FDA. In addition to clinicaltrials.gov, the flow 3200 include accessing other government-sponsored websites and/or private websites to gather information about clinical trials. In some embodiments, the flow 3200 can include using a web crawler to periodically crawl the websites 3262 and collect information about clinical trials. The flow 3200 can add information about clinical trials to a clinical trial data storage database 3264. Clinical trials may also publish research papers identifying the clinical trial's purpose as well as any clinical trial information. In some embodiments, the flow 3200 can include curating new publications 3266 as they are published and adding the publications 3266 to the clinical trial data storage database 3264. In some embodiments, the flow 3200 can use a trained machine learning model to curate the publications 3266. In some embodiments, a medical professional can manually add publications 3266 to the clinical trial data storage database 3264.”, and
Ozeran [0250] “Pharmaceutical companies and/or other institutions may maintain an institution-specific websites. The websites 3262 can include websites maintained by the pharmaceutical companies and/or other institutions. In some embodiments, the flow 3200 can include retrieving clinical trial information from one or more of the institution websites in the websites 3262. In some embodiments, the flow 3200 can include periodically querying the institution websites for clinical trial information, and adding the clinical trial information to the clinical trial data storage database 3264. Each of the websites 3262, the publications 3266, and/or the clinical trial data storage database 3264 may be treated as an independent source of clinical trial information.”); and
wherein data is stored in the database as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule (Ozeran [0116] “In some embodiments of the present disclosure, the system can create structure around clinical trial data. This can include reviewing free text (i.e., unstructured data), determining relevant information, and populating corresponding structured data field with the information. As an example, a clinical trial description may specify that only patients diagnosed with stage I breast cancer may enroll. A structured data field corresponding to “stage/grade” may then be populated with “stage I,” and a structured data field corresponding to “disease type” may then be populated with “breast” or “breast cancer.” The ability of the system to create structured clinical trial data can aid in the matching of patients to an appropriate clinical trial. In particular, a patient's structured health data can be mapped to the structured clinical trial data to determine which clinical trials may be optimal for the specific patient.”,
Ozeran [0155] “As an example, the first element shown within the inclusion criteria 511 is “histologically confirmed newly diagnosed stage I-II HER2/neu positive breast cancer.” Accordingly, within the trial details 504, “newly diagnosed” may be selected (e.g., checked), the disease criteria 513 may be selected (or otherwise input) as “breast,” and the stage/grade criteria may include “stage II, stage I, stage IIA, IIB, IA, IB.” Using GUI 500, the free-text within the inclusion criteria 511 may be mapped/associated with existing structured data fields. In some aspects, the existing structured data fields (e.g., disease criteria 513, etc.) can align with the structured data fields that may be used to capture patient data. In some situations, it may be desirable to have very granular information. Therefore, the various matching criteria fields may be fairly granular. The specificity of the matching criteria fields can enable accurate comparisons between patient data and clinical trial eligibility data, for example.”,
Ozeran [0156] “Notably, there may be several methods for creating structured data fields, such as the fields shown in FIG. 5. In some aspects, for example, system 100 may include structured data fields previously defined within an electronic medical record (EMR) or electronic data warehouse (EDW) maintained by a healthcare provider. Alternatively, system 100 may include existing structured data fields from a database maintained by a clinical laboratory, such as a laboratory that provides DNA and/or RNA sequencing; analysis of imaging features; organoid laboratory services; or other services. In some aspects, system 100 may utilize existing structured data fields from electronic data warehouses, hospitals, and health information exchanges, among other sources. In other aspects, the structured data fields may be a set of data fields appropriate for the structuring of clinical trial inclusion exclusion criteria.”, and
Ozeran [0256] “Features in the patient data store 3202 may be aggregated from many different sources, each source potentially having their own organizational and identification schema for structuring the features within the source. In some embodiments, the flow 3200 can include converting all incoming features to a common, structured format of the patient data store 3202. Similarly, clinical trial information may be aggregated from many different sources, each potentially having their own organizational and identification schema for structuring the clinical trial information within the source. In some embodiments, the flow 3200 can include converting all incoming clinical trial information to the common, structured format of the patient data store 3202 as well as an intermediate concept mapping to preserve inclusion and exclusion criteria in the original clinical trial information. In some embodiments, the websites 3262, the clinical trial data storage database 3264, the publications 3266, the pharma-sponsored clinical trial protocols 3268, and the internally curated storage database 3270 can be included in an inclusion and exclusion criteria module 3272.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the patient screening system of Kahn to incorporate the structured clinical trial data management techniques taught by Ozeran. Kahn teaches searching a patient information database to identify patients who satisfy eligibility criteria for a clinical trial and extracting a list of eligible enrollment candidates. However, Kahn does not describe organizing the patient and clinical trial data into a common structured data format. Ozeran teaches converting patient data and clinical trial information from multiple heterogeneous sources into structured data fields having predefined meanings and a common organizational schema, which enable accurate mapping between patient data and clinical trial eligibility criteria and facilitating automated patient matching. One of ordinary skill in the art would have recognized that applying Ozeran's structured data techniques to Kahn's patient screening system would have predictably improved the consistency and automation of the eligibility matching process when information is received from multiple healthcare institutions, electronic medical records, laboratories, and clinical trial repositories.
Furthermore, it would have been obvious to utilize Ozeran's structured data fields and common data format within Kahn's patient information database because organizing information into structured fields with predefined meanings is a well known database design technique that improves the efficiency and reliability of database searching, querying, and comparison operations. By storing patient and clinical trial information in a structured format having predefined fields and consistent organizational rules, Kahn's patient queries could be performed more accurately while reducing ambiguity associated with free text clinical records. The modification applies a known technique for organizing and normalizing healthcare data to the known clinical trial candidate screening process of Kahn, yielding the predictable result of more reliable identification and extraction of eligible clinical trial candidates.
Additionally, one of ordinary skill in the art would have been motivated to combine the references because both Kahn and Ozeran are directed to the same field of endeavor, computerized clinical trial patient matching, and seek to solve the common problem of efficiently identifying eligible patients from large volumes of heterogeneous medical data. Ozeran's structured data architecture complements Kahn's existing screening methodology by providing a common data representation that facilitates automated comparison between patient records and trial eligibility criteria. The combination therefore represents the predictable use of prior art elements according to their established functions to improve clinical trial candidate identification.
Regarding claim 3, Kahn and Ozeran teach the invention in claim 1, as discussed above, and further teach wherein clinical trial information is explained to the selected candidates, and consent matters are electronically recorded as a log according to a standard work procedure manual (Kahn [0102] “FIG. 20 illustrates the ManagementTask object 1816 (FIG. 18), “Give Arm A Paclataxel Treatment”. Similarly, FIG. 21 illustrates the ManagementTask object 1820, “Submit Form C-116”. The kinds of data management tasks which can be included in an iCP according to the clinical trial protocol meta-model include, for example, tasks calling for clinical personnel to submit a particular form, and a task calling for clinical personnel to obtain informed consent.”
Kahn [0107] “FIG. 3 is a screen shot of the Management_Diagram class object for the iCP, illustrating the workflow diagram for the clinical trial protocol of FIG. 2. The workflow diagram sets forth the clinical algorithm, that is, the sequence of steps, decisions and actions that the protocol specification requires to take place during the course of treating a patient under the particular protocol. The algorithm is maintained as sets of tasks organized as a graph 310, illustrated in the left-hand pane of the screen shot of FIG. 3. The protocol author adds steps and/or decision objects to the graph by selecting the desired type of object from the palate 312 in the right-hand pane of the screen shot of FIG. 3, and instantiating them at the desired position in the graph 310. Buried beneath each object in the graph 310 are fields which the protocol designer completes in order to provide the required details about each step, decision or action. The user interface of the authoring tool allows the designer to drill down below each object in the graph 310 by double-clicking on the desired object. The Management— Diagram object for the iCP also specifies a First Step (field 344), pointing to Consent & Enroll step 314, and a Last Step (field 346), which is blank.”
Kahn [0112] “FIG. 4 is a screen shot showing the result of “drilling down” on the “Consent & Enroll” step 314 (FIG. 3). As can be seen, FIG. 4 contains a sub-graph (which is also considered herein to be a “graph” in its own right) 410. The Consent & Enroll step 314 also contains certain text fields illustrated in FIG. 4 and not important for an understanding of the invention. As can be seen, graph 410 begins with a “collect pre-study variables 1” step object 410, in which the clinician is instructed to obtain certain patient medical information that does not require informed consent. Step 412 is an “obtain informed consent” step, which includes a data management task instructing the clinician to present the study informed consent form to the patient and to request the patient's signature. In another embodiment, the step 412 might include a sub-graph which instructs the clinician to present the informed consent form, and if it is not signed and returned immediately, then to schedule follow-up reminder telephone calls at future dates until the patient returns a signed form or declines to participate.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement Kahn's computerized clinical trial management system such that informed consent activities are electronically recorded as a log in accordance with a standardized clinical workflow. Kahn teaches that obtaining informed consent is a data management task within a predefined clinical protocol, that the protocol is executed according to a prescribed workflow or clinical algorithm, and that the clinician presents the informed consent form and obtains the patient's signature as part of the Consent & Enroll process. Because Kahn's protocol is managed by a computerized clinical protocol system that organizes and tracks workflow tasks, it would have been an obvious matter of design to electronically log completion of consent tasks as they occur in order to document protocol compliance, provide an auditable record of patient enrollment activities, improve traceability, reduce manual recordkeeping errors, and facilitate verification that required consent procedures were completed in accordance with standardized clinical operating procedures, which yield the predictable benefit of more reliable clinical trial administration.
Regarding claim 4, Kahn teaches target screening method for screening patients, for which a clinical trial is to be performed as targets (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”
Kahn [0129] “In one embodiment, the accrual simulation database includes one or more externally provided patient-anonymized electronic medical records databases. In another embodiment, it includes patient-anonymized data collected from various clinical sites which have participated in past studies. In the latter case the patient-anonymized data typically includes data collected by the site during either preliminary eligibility screening, further eligibility screening, or both. Preferably the database includes information about a large number of anonymous patients, including such information as the patient's current stage of several different diseases (including the possibility in each case that the patient does not have the disease); what type of prior chemotherapy the patient has undergone, if any; what type of prior radiation therapy the patient has undergone; whether the patient has undergone surgery; whether the patient has had prior hormonal therapy; metastases; and the presence of cancer in local lymph nodes. Not all fields will contain data for all patients. Preferably, the fields and values in the accrual simulation database 116 are defined according to the same CMT 112 used in the protocol meta-models and preliminary and further eligibility criteria. Such consistency of data greatly facilitates automation of the accrual simulation step 1012. Note that since the patients included in the accrual simulation database may be different from and may not accurately represent the universe of patients from which the various clinical sites executing the study will draw, some statistical correction of the numbers returned by the accrual simulation tool may be required to more accurately predict accrual.”);
extracting patients (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”);
selecting eligible persons from the targets (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”).
Kahn [0129] “In one embodiment, the accrual simulation database includes one or more externally provided patient-anonymized electronic medical records databases. In another embodiment, it includes patient-anonymized data collected from various clinical sites which have participated in past studies. In the latter case the patient-anonymized data typically includes data collected by the site during either preliminary eligibility screening, further eligibility screening, or both. Preferably the database includes information about a large number of anonymous patients, including such information as the patient's current stage of several different diseases (including the possibility in each case that the patient does not have the disease); what type of prior chemotherapy the patient has undergone, if any; what type of prior radiation therapy the patient has undergone; whether the patient has undergone surgery; whether the patient has had prior hormonal therapy; metastases; and the presence of cancer in local lymph nodes. Not all fields will contain data for all patients. Preferably, the fields and values in the accrual simulation database 116 are defined according to the same CMT 112 used in the protocol meta-models and preliminary and further eligibility criteria. Such consistency of data greatly facilitates automation of the accrual simulation step 1012. Note that since the patients included in the accrual simulation database may be different from and may not accurately represent the universe of patients from which the various clinical sites executing the study will draw, some statistical correction of the numbers returned by the accrual simulation tool may be required to more accurately predict accrual.”);
Kahn fails to explicitly teach a synthetic control arm (SCA) and who have undergone standard treatment for a new medicine; searching a database of a medical institution with search words; patients who have undergone the standard treatment in the past as targets; and wherein data is stored in the database as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule.
Ozeran teaches a synthetic control arm (SCA) and who have undergone standard treatment for a new medicine (Ozeran [0131] “The individual patient data 122 can be provided to server 120 by, for example, a data abstractor specialist (as described above). Alternatively, electronic records can be automatically transferred to server 120 from various facilities, practitioners, or third party applications, where appropriate. As shown in FIG. 1, patient data communicated to server 120 can include, but is not limited to, treatment data (such as current treatment information and resulting data), genetic data (such as RNA, DNA data), brain scans (such as PET scans, CT, MRI, etc.), and/or clinical records (such as biographical information, patient history, patient demographics, family history, comorbidity conditions, etc.).”
Ozeran [0132] “Still referring to FIG. 1, server 120 is shown to include analytics module 136, which can analyze data from database 134 (empirical patient outcomes), and individual patient data 122. Database 34 can store empirical patient outcomes for a large number of patients suffering from the same or similar conditions or diseases as patient 114. For example, “individual patient data” for numerous patients can be associated with each respective treatment and treatment outcomes, and subsequently stored in database 134. As new patient data and/or treatment data becomes available, database 134 can be updated. As one example, provider 112 may suggest a specific treatment (e.g., a clinical trial) for patient 114, and individual patient data 122 may then be included in database 134.”, and
Ozeran [0291] “Additionally, the data elements may be separated into a requirements table and a calculations table such that a study is only considered once all data elements that appear in the study's inclusion/exclusion criteria have been satisfied. Even further, data elements may be split into static and temporal classifications where a static classification is a data element that is not expected to change over time (gender, cancer site, previous treatments received, etc) and temporal classification is a data element that is subject to change (age, treatments not yet received, metastasis, smoking, blood pressure, white/red blood cell counts, etc). A patient may be recommended as potentially eligible for a clinical trial once the static classifications are all met, and the patient may be informed of the temporal classifications which need to be met. In this manner, a patient who would otherwise be eligible for a clinical trial, except that they have not had a blood test performed in the last six months may be informed that pending the results of a blood test, they may be eligible for the clinical trial. Thusly, encouraging the patient to consider getting a blood test to make their patient record more robust and potentially entering into an applicable clinical trial.”);
searching a database of a medical institution with search words (Ozeran [0249] “In some embodiments, the flow 3200 can include matching the patient with one or more clinical trials using the patient data store 3202. The patient data store 3202 can provide a number of different features as described above. The FDA requires clinical trials to register before they may enroll patients and be held. In some embodiments, the flow 3200 can include accessing registered clinical trials at one or more websites 3262, such as clinicaltrials.gov, which contains a complete listing of all clinical trials registered with the FDA. In addition to clinicaltrials.gov, the flow 3200 include accessing other government-sponsored websites and/or private websites to gather information about clinical trials. In some embodiments, the flow 3200 can include using a web crawler to periodically crawl the websites 3262 and collect information about clinical trials. The flow 3200 can add information about clinical trials to a clinical trial data storage database 3264. Clinical trials may also publish research papers identifying the clinical trial's purpose as well as any clinical trial information. In some embodiments, the flow 3200 can include curating new publications 3266 as they are published and adding the publications 3266 to the clinical trial data storage database 3264. In some embodiments, the flow 3200 can use a trained machine learning model to curate the publications 3266. In some embodiments, a medical professional can manually add publications 3266 to the clinical trial data storage database 3264.”, and
Ozeran [0250] “Pharmaceutical companies and/or other institutions may maintain an institution-specific websites. The websites 3262 can include websites maintained by the pharmaceutical companies and/or other institutions. In some embodiments, the flow 3200 can include retrieving clinical trial information from one or more of the institution websites in the websites 3262. In some embodiments, the flow 3200 can include periodically querying the institution websites for clinical trial information, and adding the clinical trial information to the clinical trial data storage database 3264. Each of the websites 3262, the publications 3266, and/or the clinical trial data storage database 3264 may be treated as an independent source of clinical trial information.”);
patients who have undergone the standard treatment in the past as targets (Ozeran [0131] “The individual patient data 122 can be provided to server 120 by, for example, a data abstractor specialist (as described above). Alternatively, electronic records can be automatically transferred to server 120 from various facilities, practitioners, or third party applications, where appropriate. As shown in FIG. 1, patient data communicated to server 120 can include, but is not limited to, treatment data (such as current treatment information and resulting data), genetic data (such as RNA, DNA data), brain scans (such as PET scans, CT, MRI, etc.), and/or clinical records (such as biographical information, patient history, patient demographics, family history, comorbidity conditions, etc.).”, and
Ozeran [0132] “Still referring to FIG. 1, server 120 is shown to include analytics module 136, which can analyze data from database 134 (empirical patient outcomes), and individual patient data 122. Database 34 can store empirical patient outcomes for a large number of patients suffering from the same or similar conditions or diseases as patient 114. For example, “individual patient data” for numerous patients can be associated with each respective treatment and treatment outcomes, and subsequently stored in database 134. As new patient data and/or treatment data becomes available, database 134 can be updated. As one example, provider 112 may suggest a specific treatment (e.g., a clinical trial) for patient 114, and individual patient data 122 may then be included in database 134.”); and
wherein data is stored in the database as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule (Ozeran [0116] “In some embodiments of the present disclosure, the system can create structure around clinical trial data. This can include reviewing free text (i.e., unstructured data), determining relevant information, and populating corresponding structured data field with the information. As an example, a clinical trial description may specify that only patients diagnosed with stage I breast cancer may enroll. A structured data field corresponding to “stage/grade” may then be populated with “stage I,” and a structured data field corresponding to “disease type” may then be populated with “breast” or “breast cancer.” The ability of the system to create structured clinical trial data can aid in the matching of patients to an appropriate clinical trial. In particular, a patient's structured health data can be mapped to the structured clinical trial data to determine which clinical trials may be optimal for the specific patient.”
Ozeran [0155] “As an example, the first element shown within the inclusion criteria 511 is “histologically confirmed newly diagnosed stage I-II HER2/neu positive breast cancer.” Accordingly, within the trial details 504, “newly diagnosed” may be selected (e.g., checked), the disease criteria 513 may be selected (or otherwise input) as “breast,” and the stage/grade criteria may include “stage II, stage I, stage IIA, IIB, IA, IB.” Using GUI 500, the free-text within the inclusion criteria 511 may be mapped/associated with existing structured data fields. In some aspects, the existing structured data fields (e.g., disease criteria 513, etc.) can align with the structured data fields that may be used to capture patient data. In some situations, it may be desirable to have very granular information. Therefore, the various matching criteria fields may be fairly granular. The specificity of the matching criteria fields can enable accurate comparisons between patient data and clinical trial eligibility data, for example.”
Ozeran [0156] “Notably, there may be several methods for creating structured data fields, such as the fields shown in FIG. 5. In some aspects, for example, system 100 may include structured data fields previously defined within an electronic medical record (EMR) or electronic data warehouse (EDW) maintained by a healthcare provider. Alternatively, system 100 may include existing structured data fields from a database maintained by a clinical laboratory, such as a laboratory that provides DNA and/or RNA sequencing; analysis of imaging features; organoid laboratory services; or other services. In some aspects, system 100 may utilize existing structured data fields from electronic data warehouses, hospitals, and health information exchanges, among other sources. In other aspects, the structured data fields may be a set of data fields appropriate for the structuring of clinical trial inclusion exclusion criteria.”
Ozeran [0256] “Features in the patient data store 3202 may be aggregated from many different sources, each source potentially having their own organizational and identification schema for structuring the features within the source. In some embodiments, the flow 3200 can include converting all incoming features to a common, structured format of the patient data store 3202. Similarly, clinical trial information may be aggregated from many different sources, each potentially having their own organizational and identification schema for structuring the clinical trial information within the source. In some embodiments, the flow 3200 can include converting all incoming clinical trial information to the common, structured format of the patient data store 3202 as well as an intermediate concept mapping to preserve inclusion and exclusion criteria in the original clinical trial information. In some embodiments, the websites 3262, the clinical trial data storage database 3264, the publications 3266, the pharma-sponsored clinical trial protocols 3268, and the internally curated storage database 3270 can be included in an inclusion and exclusion criteria module 3272.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Kahn's clinical trial patient screening system to utilize Ozeran's treatment history, empirical patient outcome database, and structured clinical trial matching techniques when identifying patients for clinical trial evaluation. Kahn teaches querying a patient information database to identify and extract patients satisfying protocol eligibility criteria, including maintaining historical treatment information such as prior chemotherapy, radiation therapy, surgery, and hormonal therapy for numerous patients to facilitate automated patient screening and accrual simulation. Ozeran further teaches maintaining patient treatment data, treatment outcomes, and clinical records for numerous patients within a database, classifying previous treatments received as patient eligibility criteria, and using structured clinical trial information to match patients to appropriate clinical trials. One of ordinary skill in the art would have recognized that incorporating Ozeran's historical treatment information and structured matching techniques into Kahn's screening process would have predictably enabled identification of patients who previously underwent a specified treatment regimen, including the standard treatment for a disease, before selecting eligible candidates for further evaluation.
Furthermore, it would have been obvious to use Ozeran's structured data architecture in Kahn's patient screening system because organizing patient treatment histories and clinical trial eligibility information into standardized structured data fields improves the accuracy and efficiency of searching, comparing, and matching patient records against clinical trial criteria. Using historical treatment information and treatment outcomes as searchable patient characteristics allows a clinical trial system to efficiently identify appropriate historical patient cohorts and subsequently determine which individuals satisfy additional eligibility requirements. The combination applies known data management and patient matching techniques to Kahn's existing clinical trial screening process to achieve the predictable result of more accurate and automated identification of eligible patients based on prior treatment history, while improving interoperability among heterogeneous medical data sources.
Regarding claim 6, Kahn teaches a clinical trial candidate screening system that screens candidates for a clinical trial, the clinical trial candidate screening system comprising (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”):
a server computer in which patient information is accumulated (Kahn [0139] “In step 120, the central authority “distributes” the iCPs from the iCP database library 118 to clinical sites which are authorized to receive them. Authorization typically involves the site being part of the central authority's network of clinical sites, and also authorization by the sponsor of each study. In one embodiment, “distribution” involves merely making the appropriate iCP databases available to the appropriate clinical sites. In another embodiment, “distribution” involves downloading the appropriate iCP databases from the iCP database library 118, into a site-local database of authorized iCPs. In yet another embodiment, the entire library 118 is downloaded to all of the member clinical sites, but keys are provided to each site only for the protocols for which that site is authorized access. Preferably, the central authority maintains the iCP databases only on the central server and makes them available using a central application service provider (ASP) and thin-client model that supports multiple user devices including work stations, laptop computers and hand held devices. The availability of hand held devices allows the deployment of “intelligent” point of care data capture devices in which all protocol-specific, visit-specific and patient-specific required data elements, and their associated data validation rules, can be automatically created using information contained within the iCP. For example, an iCP can specify that if a patient exhibits evidence of an adverse event, additional data collection elements are required. Intelligent point of care data capture can detect the existence of an adverse event and add new required data elements to completely describe the event.”);
an electronic health record system including a data warehouse (Kahn [0129] “In one embodiment, the accrual simulation database includes one or more externally provided patient-anonymized electronic medical records databases. In another embodiment, it includes patient-anonymized data collected from various clinical sites which have participated in past studies.”);
wherein the patient information input from the electronic health record system is accumulated in the server computer (Kahn [0129] “In one embodiment, the accrual simulation database includes one or more externally provided patient-anonymized electronic medical records databases. In another embodiment, it includes patient-anonymized data collected from various clinical sites which have participated in past studies.”,
Kahn [0139] “In step 120, the central authority “distributes” the iCPs from the iCP database library 118 to clinical sites which are authorized to receive them. Authorization typically involves the site being part of the central authority's network of clinical sites, and also authorization by the sponsor of each study. In one embodiment, “distribution” involves merely making the appropriate iCP databases available to the appropriate clinical sites. In another embodiment, “distribution” involves downloading the appropriate iCP databases from the iCP database library 118, into a site-local database of authorized iCPs. In yet another embodiment, the entire library 118 is downloaded to all of the member clinical sites, but keys are provided to each site only for the protocols for which that site is authorized access. Preferably, the central authority maintains the iCP databases only on the central server and makes them available using a central application service provider (ASP) and thin-client model that supports multiple user devices including work stations, laptop computers and hand held devices. The availability of hand held devices allows the deployment of “intelligent” point of care data capture devices in which all protocol-specific, visit-specific and patient-specific required data elements, and their associated data validation rules, can be automatically created using information contained within the iCP. For example, an iCP can specify that if a patient exhibits evidence of an adverse event, additional data collection elements are required. Intelligent point of care data capture can detect the existence of an adverse event and add new required data elements to completely describe the event.”);
search words converted from eligibility conditions and exclusion conditions of clinical trial information are accumulated in the clinical trial database, the accumulated patient information is searched with the search words, a matching patient can be extracted (Kahn [0054] “Some recent Web-based services aim to match sponsors and sites, based on a database of trials by sponsor and of sites' patient demographics. A related approach is to identify trials that a specific patient may be eligible for, based on matching patient characteristics against a database of eligibility criteria for active trials. This latter functionality is often embedded in a disease-specific healthcare portal such as cancerfacts.com.”
Kahn [0077] “The meta-models also include lists, again appropriate to the particular disease category, within which a protocol designer can define preliminary criteria for the eligibility of patients for a particular study. These preliminary eligibility criteria lists do not preclude a protocol designer from building further eligibility criteria into any particular clinical trial protocol. As set forth in more detail below, the options available in the lists of preliminary eligibility criteria are intentionally limited in number so as to facilitate the building of a large database of potential patients for studies within the particular disease area. At the same time, however, it is also desirable that the options be numerous or narrow enough in order to provide a good first cut of eligible patients. In order to best satisfy these two competing goals, it is desirable that an expert or a team of experts knowledgeable about the particular disease category of a particular meta-model be heavily involved in the development of the preliminary eligibility criteria lists for the particular meta-model. In addition, because of the difficulty and length of time required to develop a large database of potential patients, it is further desirable that once the eligibility criteria options are established for a particular meta-model, they do not change except as absolutely necessary. Such changes might be mandated as a result of improved understanding of a disease, for example, and are rigorously managed throughout the overall system of FIG. 1.”,
Kahn [0099] “FIG. 15 illustrates the instance of the EligibilityCriteriaSet class which appears in the CALGB 9840 iCP. It can be seen that the object contains a list of inclusion criteria and a list of exclusion criteria, each criterion of which is an instance of the ElgibilityCriterion class 1126. One of such instances 1510 is illustrated in FIG. 16. Only the short description 1610 and the long description 1612 have been entered by the protocol author.”, and Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”), and
Kahn fails to explicitly teach a terminal to which the patient information is input from each diagnosis and treatment department; a clinical trial database of a medical institution; the terminal at each diagnosis and treatment department; the patient information is accumulated in the server computer as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule.
Ozeran teaches a terminal to which the patient information is input from each diagnosis and treatment department (Ozeran 0135] “As shown, outputs from analytics module 136 can be provided to display device 116 via communication network 118. Further, provider 112 can input additional data via display device 116, and the data can be transmitted to server 120. In some embodiments, provider 112 can input clinical trial information via display device 116, and the data can be transmitted to server 120. The clinical trial information can include inclusion and exclusion criteria, site information, trial status (e.g., recruiting, active, closed, etc.), among other things.”);
a clinical trial database of a medical institution (Ozeran [0249] “In some embodiments, the flow 3200 can include matching the patient with one or more clinical trials using the patient data store 3202. The patient data store 3202 can provide a number of different features as described above. The FDA requires clinical trials to register before they may enroll patients and be held. In some embodiments, the flow 3200 can include accessing registered clinical trials at one or more websites 3262, such as clinicaltrials.gov, which contains a complete listing of all clinical trials registered with the FDA. In addition to clinicaltrials.gov, the flow 3200 include accessing other government-sponsored websites and/or private websites to gather information about clinical trials. In some embodiments, the flow 3200 can include using a web crawler to periodically crawl the websites 3262 and collect information about clinical trials. The flow 3200 can add information about clinical trials to a clinical trial data storage database 3264. Clinical trials may also publish research papers identifying the clinical trial's purpose as well as any clinical trial information. In some embodiments, the flow 3200 can include curating new publications 3266 as they are published and adding the publications 3266 to the clinical trial data storage database 3264. In some embodiments, the flow 3200 can use a trained machine learning model to curate the publications 3266. In some embodiments, a medical professional can manually add publications 3266 to the clinical trial data storage database 3264.”
Ozeran [0250] “Pharmaceutical companies and/or other institutions may maintain an institution-specific websites. The websites 3262 can include websites maintained by the pharmaceutical companies and/or other institutions. In some embodiments, the flow 3200 can include retrieving clinical trial information from one or more of the institution websites in the websites 3262. In some embodiments, the flow 3200 can include periodically querying the institution websites for clinical trial information, and adding the clinical trial information to the clinical trial data storage database 3264. Each of the websites 3262, the publications 3266, and/or the clinical trial data storage database 3264 may be treated as an independent source of clinical trial information.”);
the terminal at each diagnosis and treatment department (Ozeran [0135] “As shown, outputs from analytics module 136 can be provided to display device 116 via communication network 118. Further, provider 112 can input additional data via display device 116, and the data can be transmitted to server 120. In some embodiments, provider 112 can input clinical trial information via display device 116, and the data can be transmitted to server 120. The clinical trial information can include inclusion and exclusion criteria, site information, trial status (e.g., recruiting, active, closed, etc.), among other things.”);
the patient information is accumulated in the server computer as structured data, the structured data being a data format that is expressed with rows and columns, where each column has unique meaning, and is a data format to be managed based on a unique rule (Ozeran [0116] “In some embodiments of the present disclosure, the system can create structure around clinical trial data. This can include reviewing free text (i.e., unstructured data), determining relevant information, and populating corresponding structured data field with the information. As an example, a clinical trial description may specify that only patients diagnosed with stage I breast cancer may enroll. A structured data field corresponding to “stage/grade” may then be populated with “stage I,” and a structured data field corresponding to “disease type” may then be populated with “breast” or “breast cancer.” The ability of the system to create structured clinical trial data can aid in the matching of patients to an appropriate clinical trial. In particular, a patient's structured health data can be mapped to the structured clinical trial data to determine which clinical trials may be optimal for the specific patient.”
Ozeran [0155] “As an example, the first element shown within the inclusion criteria 511 is “histologically confirmed newly diagnosed stage I-II HER2/neu positive breast cancer.” Accordingly, within the trial details 504, “newly diagnosed” may be selected (e.g., checked), the disease criteria 513 may be selected (or otherwise input) as “breast,” and the stage/grade criteria may include “stage II, stage I, stage IIA, IIB, IA, IB.” Using GUI 500, the free-text within the inclusion criteria 511 may be mapped/associated with existing structured data fields. In some aspects, the existing structured data fields (e.g., disease criteria 513, etc.) can align with the structured data fields that may be used to capture patient data. In some situations, it may be desirable to have very granular information. Therefore, the various matching criteria fields may be fairly granular. The specificity of the matching criteria fields can enable accurate comparisons between patient data and clinical trial eligibility data, for example.”
Ozeran [0156] “Notably, there may be several methods for creating structured data fields, such as the fields shown in FIG. 5. In some aspects, for example, system 100 may include structured data fields previously defined within an electronic medical record (EMR) or electronic data warehouse (EDW) maintained by a healthcare provider. Alternatively, system 100 may include existing structured data fields from a database maintained by a clinical laboratory, such as a laboratory that provides DNA and/or RNA sequencing; analysis of imaging features; organoid laboratory services; or other services. In some aspects, system 100 may utilize existing structured data fields from electronic data warehouses, hospitals, and health information exchanges, among other sources. In other aspects, the structured data fields may be a set of data fields appropriate for the structuring of clinical trial inclusion exclusion criteria.”
Ozeran [0256] “Features in the patient data store 3202 may be aggregated from many different sources, each source potentially having their own organizational and identification schema for structuring the features within the source. In some embodiments, the flow 3200 can include converting all incoming features to a common, structured format of the patient data store 3202. Similarly, clinical trial information may be aggregated from many different sources, each potentially having their own organizational and identification schema for structuring the clinical trial information within the source. In some embodiments, the flow 3200 can include converting all incoming clinical trial information to the common, structured format of the patient data store 3202 as well as an intermediate concept mapping to preserve inclusion and exclusion criteria in the original clinical trial information. In some embodiments, the websites 3262, the clinical trial data storage database 3264, the publications 3266, the pharma-sponsored clinical trial protocols 3268, and the internally curated storage database 3270 can be included in an inclusion and exclusion criteria module 3272.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Kahn's clinical trial candidate screening system to incorporate Ozeran's centralized server architecture, provider terminal, clinical trial database, and structured patient data management techniques. Kahn teaches a centralized server that maintains clinical protocol databases, accumulates patient information from electronic medical record databases and participating clinical sites, and searches patient information to identify candidates satisfying clinical trial eligibility criteria. Ozeran further teaches provider terminals for inputting patient and clinical trial information to a server, a clinical trial database populated from multiple institutional and public sources, and centralized aggregation of patient and clinical trial information to facilitate automated patient to trial matching. One of ordinary skill in the art would have recognized that incorporating Ozeran's provider terminals and centralized clinical trial database into Kahn's screening system would have predictably improved the collection, organization, and availability of patient and clinical trial information from multiple diagnosis and treatment departments while maintaining the centralized patient screening functionality already taught by Kahn.
Furthermore, it would have been obvious to organize the accumulated patient information within Kahn's server using Ozeran's structured data architecture because Ozeran teaches converting heterogeneous patient records and clinical trial information into common structured data fields to enable accurate comparison between patient characteristics and eligibility criteria. Applying Ozeran's structured data techniques to Kahn's centralized patient database would have improved the consistency and efficiency of database searching, eligibility matching, and candidate extraction by reducing ambiguity associated with unstructured clinical records and allowing patient information received from electronic health record systems, provider terminals, and multiple medical institutions to be uniformly processed. The proposed combination merely applies known data normalization and centralized data management techniques to Kahn's known clinical trial screening system, yielding the predictable result of more reliable and automated identification of eligible clinical trial candidates while improving data integration across multiple healthcare information sources.
Regarding claim 8, Kahn and Ozeran teach the invention in claim 6, as discussed above, and further teach wherein personal information of a patient is stored in a server storage unit along with a patient ID and an anonymized ID (Kahn [0139] “In step 120, the central authority “distributes” the iCPs from the iCP database library 118 to clinical sites which are authorized to receive them. Authorization typically involves the site being part of the central authority's network of clinical sites, and also authorization by the sponsor of each study. In one embodiment, “distribution” involves merely making the appropriate iCP databases available to the appropriate clinical sites. In another embodiment, “distribution” involves downloading the appropriate iCP databases from the iCP database library 118, into a site-local database of authorized iCPs. In yet another embodiment, the entire library 118 is downloaded to all of the member clinical sites, but keys are provided to each site only for the protocols for which that site is authorized access. Preferably, the central authority maintains the iCP databases only on the central server and makes them available using a central application service provider (ASP) and thin-client model that supports multiple user devices including work stations, laptop computers and hand held devices”,
Kahn [0143] “FIG. 26 is a flow chart detail of step 122 (FIG. 1). The steps in FIG. 1 typically use or contribute to a site-private patient information database 2610, which contains a number of different kinds of patient information. Because this information is maintained in conjunction with the identity of the patient, these databases 2610 are typically confidential to the clinical site or SMO, and not made available to anyone else, including study sponsors and the central authority. In one embodiment, the patient information database 2610 is located physically at the clinical site. In another embodiment, storage of the database 2610 is provided by the central authority as a service to clinical sites. In the latter embodiment, cryptographic or other security measures may be taken to ensure that no entity but the individual clinical site can view any confidential patient information.”, and
Kahn [0144] “As shown in FIG. 1, the central authority also maintains its own “operational” database 124, containing patient-anonymized patient information. The operational database 124 can be separate from the confidential patient information database(s) 2610 in which case a patient anonymized version of the patient information database 2610, or at least portions of database 2610, are transferred periodically for inclusion in an operational database 124 (FIG. 1). Alternatively, the two databases can be integrated together into one, with the central authority being denied access to sensitive patient-confidential information cryptographically.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to store personal information together with both a patient ID and an anonymized ID, because Kahn teaches maintaining confidential patient identifiers at the site level while generating anonymized versions for use by external systems such as the central authority. Using these paired identifiers to separate personally identifiable information from anonymized operational data reflects a routine security architecture in clinical systems.
Regarding claim 9, Kahn and Ozeran teach the invention in claim 6, as discussed above, and further teach comprising a mechanism that creates and checks an electronic consent form, the mechanism confirming and recording consent matters for the candidates for the clinical trial (Kahn [0102] “FIG. 20 illustrates the ManagementTask object 1816 (FIG. 18), “Give Arm A Paclataxel Treatment”. Similarly, FIG. 21 illustrates the ManagementTask object 1820, “Submit Form C-116”. The kinds of data management tasks which can be included in an iCP according to the clinical trial protocol meta-model include, for example, tasks calling for clinical personnel to submit a particular form, and a task calling for clinical personnel to obtain informed consent.”, and
Kahn [0107] “FIG. 3 is a screen shot of the Management_Diagram class object for the iCP, illustrating the workflow diagram for the clinical trial protocol of FIG. 2. The workflow diagram sets forth the clinical algorithm, that is, the sequence of steps, decisions and actions that the protocol specification requires to take place during the course of treating a patient under the particular protocol. The algorithm is maintained as sets of tasks organized as a graph 310, illustrated in the left-hand pane of the screen shot of FIG. 3. The protocol author adds steps and/or decision objects to the graph by selecting the desired type of object from the palate 312 in the right-hand pane of the screen shot of FIG. 3, and instantiating them at the desired position in the graph 310. Buried beneath each object in the graph 310 are fields which the protocol designer completes in order to provide the required details about each step, decision or action. The user interface of the authoring tool allows the designer to drill down below each object in the graph 310 by double-clicking on the desired object. The Management— Diagram object for the iCP also specifies a First Step (field 344), pointing to Consent & Enroll step 314, and a Last Step (field 346), which is blank.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to incorporate a mechanism that creates, checks, and records electronic consent forms, because Kahn teaches protocol management tasks, which include obtaining informed consent and generating or submitting required forms. Integrating electronic consent workflows into a clinical trial candidate screening system represents a routine extension of protocol management functionality and provides predictable operational benefits.
Regarding claim 10, Kahn and Ozeran teach the invention in claim 6, as discussed above, and further teach comprising a mechanism that performs anonym processing information processing of the patient information so that subjects can be selected while protecting personal information (Kahn [0144] “As shown in FIG. 1, the central authority also maintains its own “operational” database 124, containing patient-anonymized patient information. The operational database 124 can be separate from the confidential patient information database(s) 2610 in which case a patient anonymized version of the patient information database 2610, or at least portions of database 2610, are transferred periodically for inclusion in an operational database 124 (FIG. 1). Alternatively, the two databases can be integrated together into one, with the central authority being denied access to sensitive patient-confidential information cryptographically.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to include a mechanism that performs anonymization of patient information, as Kahn teaches maintaining an operational database containing anonymized patient data and discusses techniques for ensuring that sensitive patient secure information is protected from unauthorized access. Implementing this anonymization within the screening system yields the predictable way of enabling subject selection while preserving privacy.
Regarding claim 11, Kahn and Ozeran teach the invention in claim 6, as discussed above, and further teach a method using the clinical trial candidate screening system, comprising (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”):
converting eligibility conditions and exclusion conditions of a clinical trial into search words (Kahn [0054] “Some recent Web-based services aim to match sponsors and sites, based on a database of trials by sponsor and of sites' patient demographics. A related approach is to identify trials that a specific patient may be eligible for, based on matching patient characteristics against a database of eligibility criteria for active trials. This latter functionality is often embedded in a disease-specific healthcare portal such as cancerfacts.com.”
Kahn [0077] “The meta-models also include lists, again appropriate to the particular disease category, within which a protocol designer can define preliminary criteria for the eligibility of patients for a particular study. These preliminary eligibility criteria lists do not preclude a protocol designer from building further eligibility criteria into any particular clinical trial protocol. As set forth in more detail below, the options available in the lists of preliminary eligibility criteria are intentionally limited in number so as to facilitate the building of a large database of potential patients for studies within the particular disease area. At the same time, however, it is also desirable that the options be numerous or narrow enough in order to provide a good first cut of eligible patients. In order to best satisfy these two competing goals, it is desirable that an expert or a team of experts knowledgeable about the particular disease category of a particular meta-model be heavily involved in the development of the preliminary eligibility criteria lists for the particular meta-model. In addition, because of the difficulty and length of time required to develop a large database of potential patients, it is further desirable that once the eligibility criteria options are established for a particular meta-model, they do not change except as absolutely necessary. Such changes might be mandated as a result of improved understanding of a disease, for example, and are rigorously managed throughout the overall system of FIG. 1.,
Kahn [0099] “FIG. 15 illustrates the instance of the EligibilityCriteriaSet class which appears in the CALGB 9840 iCP. It can be seen that the object contains a list of inclusion criteria and a list of exclusion criteria, each criterion of which is an instance of the ElgibilityCriterion class 1126. One of such instances 1510 is illustrated in FIG. 16. Only the short description 1610 and the long description 1612 have been entered by the protocol author.”);
extracting patients who match the conditions using the clinical trial candidate screening system (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”); and
determining whether the eligibility conditions and the exclusion conditions of the clinical trial are appropriate by grasping the number of patients who match the conditions (Kahn [0077] “The meta-models also include lists, again appropriate to the particular disease category, within which a protocol designer can define preliminary criteria for the eligibility of patients for a particular study. These preliminary eligibility criteria lists do not preclude a protocol designer from building further eligibility criteria into any particular clinical trial protocol. As set forth in more detail below, the options available in the lists of preliminary eligibility criteria are intentionally limited in number so as to facilitate the building of a large database of potential patients for studies within the particular disease area. At the same time, however, it is also desirable that the options be numerous or narrow enough in order to provide a good first cut of eligible patients. In order to best satisfy these two competing goals, it is desirable that an expert or a team of experts knowledgeable about the particular disease category of a particular meta-model be heavily involved in the development of the preliminary eligibility criteria lists for the particular meta-model. In addition, because of the difficulty and length of time required to develop a large database of potential patients, it is further desirable that once the eligibility criteria options are established for a particular meta-model, they do not change except as absolutely necessary. Such changes might be mandated as a result of improved understanding of a disease, for example, and are rigorously managed throughout the overall system of FIG. 1.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to convert clinical trial eligibility and exclusion criteria into searchable terms, extract matching patients using the screening system, and determine appropriateness of the criteria based on how many patients match, because Kahn teaches using eligibility criteria in structured list form, using the structured criteria to query patient databases, and evaluating whether the criteria are too restrictive or too broad in order to facilitate trial feasibility. Kahn further teaches using eligibility criteria as searchable elements for automated patient matching. Applying these known steps represents a predictable use of existing clinical trial feasibility tools and query matching techniques.
Regarding claim 12, Kahn and Ozeran teach the invention in claim 6, as discussed above, and further teach an adverse event analysis method for analyzing adverse events by a medicine using the clinical trial candidate screening system, the adverse event analysis method comprising (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”, and
Kahn [0139] “For example, an iCP can specify that if a patient exhibits evidence of an adverse event, additional data collection elements are required. Intelligent point of care data capture can detect the existence of an adverse event and add new required data elements to completely describe the event.”):
extracting patients who have used a medicine for which analysis is to be performed using the clinical trial candidate screening system (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”); and
analyzing examination values, observation and symptoms at the time of use of the medicine (Ozeran [0238] “In some embodiments, the flow 3200 can include generating and/or receiving a number of clinical data features 3212 associated with the patient. The patient data store 3202 can include the clinical data features 3212. The clinical features 3212 can be derived from curated records 3214, structured records 3216, and/or electronic medical and/or health records 3218.”, and
Ozeran [0239] “In some embodiments, the clinical features 3212 can include features such as diagnosis, symptoms, therapies, outcomes, patient demographics such as patient name, date of birth, gender, ethnicity, date of death, address, smoking status, diagnosis dates for cancer, illness, disease, diabetes, depression, and/or other physical or mental maladies, personal medical history, or family medical history, clinical diagnoses such as date of initial diagnosis, date of metastatic diagnosis, cancer staging, tumor characterization, tissue of origin, treatments and outcomes such as line of therapy, therapy groups, clinical trials, medications prescribed or taken, surgeries, radiotherapy, imaging, adverse effects, associated outcomes, and/or corresponding dates, and genetic testing and laboratory information such as genetic testing, performance scores, lab tests, pathology results, prognostic indicators, or corresponding dates, and/or more detailed information including date of genetic testing, testing provider used, testing method used, such as genetic sequencing method and/or gene panel, gene results, such as included genes, variants, and/or expression levels/statuses. In some embodiments, the clinical features 3212 can include a unified record database 3220. The unified record database 3220 can include copies of any of the above clinical features structured in a unified format. The unified format can allow the flow 3200 to disseminate patient features regardless of the original format the patient features were stored in, which may be helpful when matching patients from different medical systems with clinical trials.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Kahn's clinical trial candidate screening system to analyze examination values, observations, and symptoms associated with patients who have used a medicine by utilizing Ozeran's comprehensive clinical feature analysis techniques. Kahn teaches extracting patients from a patient information database and detecting adverse events that trigger the collection of additional patient data to more completely describe the event, while Ozeran teaches maintaining and analyzing clinical features including symptoms, therapies, medications, adverse effects, laboratory test results, pathology results, imaging, diagnoses, outcomes, and other examination data associated with patients. One of ordinary skill in the art would have recognized that incorporating Ozeran's analysis of comprehensive clinical features into Kahn's adverse event monitoring system would have predictably improved the ability to evaluate adverse events associated with a particular medication by providing a more complete analysis of patient examination values, observations, and symptoms using known clinical information maintained in electronic medical records, which improves the accuracy and clinical usefulness of adverse event assessments while employing each reference according to its established function.
Regarding claim 13, Kahn and Ozeran teach the invention in claim 6, as discussed above, and further teach a search method for searching a clinical trial that matches a patient using the clinical trial candidate screening system, the search method comprising (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”):
referring to data that is structured data of patient information of the patient using search words converted so as to enable search, from clinical trial information accumulated in the clinical trial database for each clinical trial (Kahn [0146] “After the clinical site has decided to proceed with a study, then it can use either a “Find-Me Patients” tool (step 2614) or a “QuickScreen” tool (step 2616) to identify enrollment candidates. The “Find-Me Patients” tool is either the same or different from the local accrual simulation tool, and it operates to develop a list of patients from its patient information database 2610 who are likely to satisfy the eligibility criteria for a particular protocol. Again, this local “Find-Me Patients” tool makes appropriate queries to the patient information database 2610 for patients who are believed to satisfy the preliminary eligibility criteria for the subject protocol.”, and
Kahn [0129] “In one embodiment, the accrual simulation database includes one or more externally provided patient-anonymized electronic medical records databases. In another embodiment, it includes patient-anonymized data collected from various clinical sites which have participated in past studies. In the latter case the patient-anonymized data typically includes data collected by the site during either preliminary eligibility screening, further eligibility screening, or both. Preferably the database includes information about a large number of anonymous patients, including such information as the patient's current stage of several different diseases (including the possibility in each case that the patient does not have the disease); what type of prior chemotherapy the patient has undergone, if any; what type of prior radiation therapy the patient has undergone; whether the patient has undergone surgery; whether the patient has had prior hormonal therapy; metastases; and the presence of cancer in local lymph nodes. Not all fields will contain data for all patients. Preferably, the fields and values in the accrual simulation database 116 are defined according to the same CMT 112 used in the protocol meta-models and preliminary and further eligibility criteria. Such consistency of data greatly facilitates automation of the accrual simulation step 1012. Note that since the patients included in the accrual simulation database may be different from and may not accurately represent the universe of patients from which the various clinical sites executing the study will draw, some statistical correction of the numbers returned by the accrual simulation tool may be required to more accurately predict accrual.”).);
extracting a matching clinical trial (Kahn [0054] “Some recent Web-based services aim to match sponsors and sites, based on a database of trials by sponsor and of sites' patient demographics. A related approach is to identify trials that a specific patient may be eligible for, based on matching patient characteristics against a database of eligibility criteria for active trials. This latter functionality is often embedded in a disease-specific healthcare portal such as cancerfacts.com.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to use structured patient data and search terms to query clinical trial information and extract matching trials, because Kahn teaches organizing patient and trial eligibility data in structured form, converting eligibility criteria into standardized searchable representations, and identifying matching trials based on comparison of patient attributes to trial eligibility criteria. Employing this structured data and searchable terms to retrieve matching trials represents a routine database search operation that is widely used in clinical trial matching systems.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted on 05/18/2026 with respect to the rejection of the claims have been carefully considered and is addressed below.
Drawings
In view of Applicant’s submission of compliant replacement drawing sheet(s), the objection to the drawings is withdrawn.
Claim Rejections - 35 USC § 101
Applicant's arguments have been fully considered but are not persuasive. Applicant states that the amended limitations reciting that the structured data is expressed with rows and columns, where each column has unique meaning and is managed based on a unique rule, integrate the judicial exception into a practical application because the structured data enables efficient searching using search words. However, these limitations describe a conventional manner of organizing and storing information within a database and do not recite any improvement to computer functionality or another technology. The claims do not recite any specialized database architecture, indexing technique, search algorithm, or other technological mechanism that improves the operation of the computer itself. Instead, the structured data is merely used as a tool for implementing the abstract mental process of reviewing patient information, comparing the patient information to predetermined eligibility criteria of search words, and identifying eligible patients.
Applicant further states that the claimed structured data improves searching technology by allowing large amounts of data to be processed rapidly and with lower hardware specifications. However, these alleged benefits are not commensurate with the scope of the claims. The claims recite storing information as structured data and searching the stored data using search words, without reciting any particular technological implementation that achieves the improvements in efficiency or hardware utilization. The improvement is in speed from using generic computer components to automate the abstract idea instead of an improvement to the functioning of the computer or another technology. Accordingly, the additional elements do not integrate the judicial exception into a practical application under Step 2A, Prong Two.
Applicant's statements with respect to Step 2B are also unpersuasive. The recited server computer, electronic health record system, clinical trial database, and structured data format are generic computer components perform conventional functions of collecting and retrieving information. The claims do not recite any unconventional computer functionality or technological improvement that amounts to significantly more than the abstract idea itself. Instead, the claims automate the abstract mental process using generic computer technology. Therefore, the claims do not recite an inventive concept sufficient to transform the judicial exception into patent eligible subject matter and the rejection under 35 U.S.C. 101 is maintained.
Claim Rejections - 35 USC § 102
In light of Applicant’s amendment and arguments, the rejection of the claims under 35 U.S.C. 102 is withdrawn.
Claim Rejections - 35 USC § 103
Applicant’s arguments traversing the prior art rejection in the previous Office Action have been fully considered. However, those arguments are rendered moot because the present rejection under 35 U.S.C. §103 relies on a different set of prior art references (Kahn and Ozeran), which teach or suggest the limitations of the claims. Accordingly, Applicant’s prior arguments are not responsive to the current grounds of rejection. The rejection of claims 1, 3-4, 6, and 8-13 under 35 U.S.C. §103 is therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure.
Fusari et al. (U.S. Patent Publication 2016/0314280) teaches a federated data repository system that translates study queries across heterogeneous data sources to identify potential candidates for participation in a clinical study.
Mao et al. (U.S. Patent Publication 2020/0234801 A1) teaches a method for recruiting a clinical trial patient that standardizes eligibility criteria from multiple tools, stores them in a database, receives patient specific data, queries the standardized criteria to determine which trials the patient satisfies, and outputs a report identifying the matching trial.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kambiz Abdi can be reached at (571)272-6702. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685
Prosecution Insights