WO2024233438A1 - Systems and methods for managing, storing, organizing, and classifying clinical health data associated with medical devices - Google Patents

Abstract

Techniques for managing, storing, organizing, and/or classifying clinical health data associated with medical devices can include receiving a plurality of electronic health records associated with one or more medical devices and a patient population. The health records can be ingested and indexed by normalizing the records to generate a corpus of clinical health data associated with the one or more medical devices. The corpus of clinical health data can be searched by providing a search request that identifies a medical device via a search interface. Relevant clinical health data associated with the requested medical device can be retrieved and output. The corpus can be updated and monitored to detect events of interest, upon which an alert can be output.

Description

SYSTEMS AND METHODS FOR MANAGING, STORING, ORGANIZING, AND CLASSIFYING CLINICAL HEALTH DATA ASSOCIATED WITH MEDICAL DEVICES

PRIORITY CLAIM

[0001] This application claims the benefit of U.S. Provisional Application No. 63/464,333, filed May 5, 2023. The entire disclosure of the above application is incorporated by reference.

FIELD

[0002] The present disclosure relates to a computerized system and method for storing, categorizing, organizing, and retrieving clinical health data, e.g., for monitoring the performance of medical devices.

BACKGROUND

[0003] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Medical devices are a highly regulated field. Regulatory agencies typically require medical device manufacturers to gather clinical health data associated with a medical device in order to approve the use (or continued use) of the medical device. More and more frequently, regulatory agencies are requiring medical device manufacturers to assemble comprehensive assessments of current real-world patient data for such purposes. Conventionally, assembling such assessments based on real-world patient data is performed manually by a human being, which can be exceedingly time-consuming, costly, and prone to errors. Accordingly, there is a need for an improved manner of storing, retrieving, organizing, categorizing, etc. clinical health data associated with such medical device assessments.

SUMMARY

[0005] In some implementations of the present disclosure, a computer-implemented method for managing, storing, organizing, and/or classifying clinical health data associated with medical devices is disclosed. The method can include receiving, at a healthcare provider computing device, a plurality of electronic health records associated with one or more medical devices and a patient population. Each of the plurality of electronic health records can be associated with a particular patient and comprising: (i) patient data regarding the particular patient (ii) medical device data identifying and corresponding to a particular medical device of the particular patient, (ill) diagnosis data corresponding to a particular diagnosis of the particular patient, (iv) procedure data corresponding to a particular procedure of the particular patient, (v) healthcare provider notes regarding the particular patient; and (vi) outcome data corresponding to a particular outcome associated with the particular patient. The method can further include ingesting, at the healthcare provider computing device, the plurality of electronic health records by normalizing at least one of the patient data, the medical device data, the diagnosis data, or the procedure data for the patient population. Normalizing the data can comprise utilizing artificial intelligence to identify commonalities among different features in the plurality of electronic health records.

[0006] Additionally, the method can include indexing, at the healthcare provider computing device, the ingested plurality of electronic health records to obtain a corpus of clinical health data associated with the one or more medical devices. The corpus of clinical health data can comprise a searchable database of the clinical health data, wherein the identified commonalities are linked in the corpus of clinical health data such that the different features are grouped together. The method can include providing, from the healthcare provider computing device, a search interface for the searchable database of the clinical health data to a user computing device associated with a user. Further, the method can also include receiving, at the healthcare provider computing device and from the user computing device via the search interface, a search request for relevant clinical health data associated with a requested medical device of the one or more medical devices, where the search request identifying the requested medical device. The method can additionally include retrieving, at the healthcare provider computing device, the relevant clinical health data associated with the requested medical device and outputting, from the healthcare provider computing device and to the user computing device, the relevant clinical health data associated with the requested medical device. The relevant clinical health data corresponding to a patient subpopulation of the patient population.

[0007] In some aspects, the patient data can comprise demographic data of the particular patient, the demographic data including at least one of a sex, an age, an ethnicity, or a race of the particular patient.

[0008] In some aspects, outputting the relevant clinical health data associated with the requested medical device can include: generating a summary of the relevant clinical health data, and providing a graphical user interface (“GUI”) to the user computing device, wherein the GUI indudes the summary of the relevant clinical health data and one or more selectable elements for further refining the relevant clinical health data. The summary can include: a number of electronic health records in the relevant clinical health data, a number of health provider visits in the relevant clinical health data, a number of diagnoses in the relevant clinical health data, and a number of procedures in the relevant clinical health data, in additional or alternative aspects, the summary can include a number of medications corresponding to the patient subpopulation in the relevant clinical health data, a number of allergies corresponding to the patient subpopulation in the relevant clinical health data, and an indication of where the medical device is used.

[0009] In some aspects, the one or more selectable elements for further refining the relevant clinical health data can be configured to filter the relevant clinical health data based on at least one of the patient data, the diagnosis data, the procedure data, or the healthcare provider notes.

[0010] In some aspects, the method can further include grouping, at the healthcare provider computing device and utilizing a machine learning algorithm, each patient in the patient subpopulation into one or more categories of a plurality of categories based on their corresponding electronic health record, and generating, at the healthcare provider computing device, a patient record for each patient in the patient subpopulation, each patient record including the one or more categories in which its corresponding patient is grouped, wherein outputting the relevant clinical health data associated with the requested medical device comprises providing a graphical user interface (“GUI”) configured to display the patient records.

[0011] In some aspects, each patient record can further include: (I) the patient data, (ii) the diagnosis data, (iii) the procedure data, (iv) the healthcare provider notes of its corresponding patient, and (v) the outcome data.

[0012] In some aspects, the method can further include receiving, at the healthcare provider computing device and from the user computing device via the GUI, a validation input for each patient record, the validation input corresponding to a manual approval or a manual rejection of the one or more categories in which its associated patient is grouped.

[0013] In some aspects, the method can further include updating, at the healthcare provider computing device, the relevant clinical health data associated with the requested medical device based on the validation inputs. Updating the relevant clinical health data can include removing certain patients from the patient subpopulation. [0014] In some aspects, the method can further include adapting the machine learning algorithm based on the validation inputs.

[0015] In some aspects, generating the patient record for each patient can comprise utilizing the artificial intelligence to: (I) analyze the electronic health record for the corresponding patient to determine a relevance of each portion of the electronic health record to the search request, (ii) rank the portions of the electronic health record based on their determined relevance, and (iii) accentuate one or more portions in the electronic health record based on the ranking. Accentuating the one or more portions in the electronic health record based on the ranking can comprise utilizing the artificial intelligence to generate a summary of the one or more portions, wherein the summary is included in the electronic health record.

[0016] In some aspects, the plurality of categories can include a safety category, a clinical benefit category, a performance category, and an undetermined category.

[0017] In some aspects, the method can further include updating, at the healthcare provider computing device, the corpus of clinical health data in real time based on receiving: (i) one or more additional electronic health records, or (ii) additional information corresponding to a previously received electronic health record. The additional information can correspond to a previously unknown health provider visit.

[0018] In some aspects, the method can further comprise automatically analyzing, at the healthcare provider computing device, the updated corpus of clinical health data to determine whether an event of interest has occurred, and outputting, from the healthcare provider computing device, an alert when the event of interest has occurred. The event of interest can correspond to an adverse event or off-label use associated with the one or more medical devices. Further, automatically analyzing the updated corpus of clinical health data to determine whether the event of interest has occurred can comprise utilizing a machine learning algorithm to detect the event of interest. The machine learning algorithm can comprise a classification algorithm, a clustering algorithm, or a neural network process.

[0019] In some aspects, the healthcare provider notes can include unstructured text, and utilizing artificial intelligence to identify commonalities among different features in the plurality of electronic health records can comprise utilizing a natural language processing algorithm to process the unstructured text to identify the commonalities between the healthcare provider notes in the plurality of electronic health records.

[0020] In further aspects, the present disclosure is directed to a computing system, comprising: one or more processors; and a non-transitory computer-readable storage medium having a plurality of instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations corresponding to the methods discussed above.

[0021] In even further aspects, the present disclosure is directed to a non-transitory computer-readable storage medium having a plurality of instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations corresponding to the methods discussed above :

[0022] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples are Intended for purposes of illustration only and are not intended to limit the scope of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The present disclosure will become more fully understood from the detailed description and the accompanying drawings, wherein:

[0024] FIG. 1 is a diagram of an example healthcare computing system including a plurality of healthcare provider computing devices and user computing devices communicating over a network according to some implementations of the present disclosure;

[0025] FIG. 2 is a functional block diagram of an example healthcare provider computing device of FIG. 1;

[0026] FIG. 3 is an illustration of an example graphical user interface presented to a user in accordance with a clinical health data storage tool according to some implementations of the present disclosure;

[0027] FIG. 4 is an illustration of is an illustration of another example graphical user interface presented to a user that displays statistics associated with a selected medical device according to some implementations of the present disclosure;

[0028] FIGs. 5-7 are illustrations of example graphical user interfaces that a user can utilize to refine clinical health data according to some implementations of the present disclosure;

[0029] FIGs. 8-11 are illustrations of graphical user interfaces displaying different examples of patient records according to some implementations of the present disclosure; [0030] FIG. 12 is a flow chart of an example method of managing, storing, organizing, and/or classifying clinical health data associated with medical devices according to some implementations of the present disclosure; [0031] FIG. 13 is a flow chart of another example method of managing, storing, organizing, and/or classifying clinical health data associated with medical devices according to some implementations of the present disclosure; and

[0032] FIG. 14 is a flow chart of an example method of detecting and outputting events of interest associated with medical devices according to some implementations of the present disclosure.

DETAILED DESCRI PTION

[0033] As mentioned above, a need exists for an improved manner of storing, retrieving, organizing, categorizing, etc. clinical health data associated with medical devices, e.g., in order to generate medical device assessments. Conventional techniques that utilize manual (human) based gathering and categorization of such data are not only time consuming and relatively expensive, but also may be error prone due to relying solely on human judgement and assessment of the source data. A typical manner of attempting to reduce such errors is to utilize more highly trained or skilled human reviewers, and/or to include more layers of manual review, which results in an increased expense. Accordingly, accuracy and error reduction are typically viewed as factors to be balanced against cost/expense. In contrast, the techniques of the present disclosure provide increased accuracy and error reduction without such a tradeoff.

[0034] In accordance with the present disclosure, the present techniques provide for a clinical health data storage tool to store, organize, classify, manage, etc. clinical health data associated with medical devices. More specifically, the tool of the present disclosure utilizes artificial intelligence or other forms of machine learning to gather, correlate, characterize, organize, and/or analyze patient data associated with one or more medical devices in order to generate assessments or other data exports, e.g., that can be utilized by a medical device manufacturer to comply with its regulatory obligations. Additionally or alternatively, the tool of the present disclosure can analyze health data associated with medical devices in order to identify potentially adverse (or other unexpected) events associated with a medical device. The tool further provides a workbench that manual reviewers can utilize to access, characterize, and/or analyze such data in a highly organized and comprehensive manner. These techniques are further described below.

[0035] Referring now to FIG. 1 , a diagram of an example healthcare computing system 100 is illustrated. The computing system 100 can include a plurality of example healthcare provider computing devices 110 and a plurality of example user computing devices 120 that communicate via a network 130 according to some implementations of the present disclosure. The computing system 100 can also include a plurality of electronic memory devices 115 associated with the healthcare provider computing devices 110. Each of the user computing devices 120 can be associated with one or more users 125. For ease of description, in this application and as shown in FIG. 1 , two example healthcare provider computing devices 110 (a first healthcare provider computing device 110-1 and a second healthcare provider computing device 110-2), in communication with two electronic memory devices 115 (a first electronic memory device 115-1 and a second electronic memory device 115-2), and one example user computing device 120 are illustrated and described. It should be appreciated, however, that there can be more healthcare provider computing devices 110, and/or user computing devices 120 than is illustrated. Further, although the electronic memory devices 115 are illustrated as being separate from the healthcare provider computing devices 110 (such as by being remote or in the “cloud”), it should be appreciated that the electronic memory devices 115 can alternatively be a component of or otherwise integrated into the healthcare provider computing devices 110. While illustrated as a server computing device and a desktop computing device, respectively, each of the healthcare provider computing devices 110 and user computing devices 120 can be any type of suitable computing device, such as a tablet computer, a laptop computer, a smartphone, or any form of processor.

[0036] A functional block diagram of an example healthcare provider computing device 110 is illustrated in FIG. 2. The healthcare provider computing device 110 can include a communication element 200, one more processors 210, a memory 220, a display device 230, and an application 240 that is being executed (referred to herein as “application 240”). The processor(s) 210 can control operation of the healthcare provider computing device 110, including implementing at least a portion of the techniques of the present disclosure. The term “processor” as used herein is intended to refer to both a single processor and multiple processors operating together, e.g., in a parallel or distributed architecture. The communication element 200 can be configured for communication with other devices (e.g., the user computing devices 120, other healthcare provider computing devices 110, and/or the electronic memory devices 115) via the network 130 or other communication medium. One non-limiting example of the communication element 200 is a transceiver, although other forms of hardware are within the scope of the present disclosure. The memory 220 can be any suitable storage medium (flash, hard disk, etc.) configured to store information. For example, the memory 220 may store a set of instructions that are executable by the processor 210, which cause the healthcare provider computing device 110 to perform operations, e.g., such as the operations of the present disclosure. The display device 230 can display information to a user. In some implementations, the display device 230 can comprise a touch-sensitive display device (such as a capacitive touchscreen and the like), although non-touch display devices are within the scope of the present disclosure. The application 240 can be a computer program configured to perform the techniques of the present disclosure.

[0037] It should be appreciated that the example user computing devices 120 can include the same or similar components as the healthcare provider computing device 110, and thus can be configured to perform some or all of the techniques of the present disclosure, which are described more fully below. Further, while the techniques of the present disclosure are described herein in the context of the healthcare computing system 100, it is specifically contemplated that each feature of the techniques may be performed by a healthcare provider computing device 110 alone, a plurality of healthcare provider computing devices 110 operating together, a user computing device 120 alone, a plurality of user computing devices 110 operating together, and any combination of one or more healthcare provider computing devices 110 and one or more user computing devices 120 operating together.

[0038] As briefly mentioned above, the present disclosure is directed to techniques for storing, retrieving, organizing, categorizing, etc. clinical health data associated with medical devices. Such clinical health data can be useful in various ways, from complying with regulatory obligations, to providing additional feedback as to the efficacy of medical devices, and/or to provide for early detection of changes in the use and efficacy of medical devices. Clinical health data is typically generated during patient visits with healthcare providers, such as doctors or other medical service providers. Even with so-called “standardized” medical coding requirements, the generated clinical health data can be incomplete, inaccurate, or ambiguous, e.g., due to human error, and/or because there may be subjectivity involved with assigning medical coding (due to coding overlap and the like). Thus, even properly medically coded clinical health data may not capture the full collection of similarly situated patient data or provide the most accurate basis for comparing health records.

[0039] Additionally, clinical health data can be extremely detailed, voluminous, cumbersome, and difficult to parse. Raw clinical health data (that is, in its original form when received from health providers) may only be able to be interpreted by highly trained and skilled individuals. Even with highly trained individuals, the review and classification of raw clinical health data may take a relatively long time to process because of the amount of data involved. Furthermore, typical forms of quality checking the results of a manual review and classification process may be satisfactory for detecting overinclusion of patient records in a grouping (by reprocessing the patient records that are included, which may be less than the entirety of all patient records), but may not be sufficiently able to identify underinclusion of patient data without re-performing the entire process. Accordingly, there is a need for improved techniques for storing, retrieving, organizing, and categorizing clinical health data.

[0040] The present disclosure is directed to a clinical health data tool and associated platform for automating the ingesting, storing, retrieving, organizing, categorizing, etc. clinical health data associated with medical devices. The tool receives electronic health records associated with a patient population, and operates to ingest and index the electronic health records to obtain a corpus of clinical health data relating to the patient population. Each electronic health record can be associated with an individual patient and can include some or all of patient data, medical device data, diagnosis data, procedure data, and outcome data.

[0041] The ingesting of the electronic health records can include utilizing artificial intelligence (such as a machine learning model or similar) to normalize the health records to be in a standardized form. In some aspects, health records may include healthcare provider notes in the form of unstructured text. For such health records, the tool can utilize artificial intelligence (such as a natural language processing algorithm) to process the unstructured text to interpret, summarize, determine the meaning of, and/or extract other features of the unstructured text in order to identify the commonalities between health records. In this manner, the ingested and indexed clinical health data in the corpus can be made to be a searchable database that permits simple comparisons between, and other analyses of, the individual records in the clinical health data.

[0042] In some implementations of the present disclosure, the described tool can also provide a search interface that is utilized by a user 125 (via user computing device 120) to perform a search for relevant clinical health data. A user 125 can input a search request via the search interface to retrieve clinical health data associated with a particular medical device. The searchable database can be accessed by the tool, which can retrieve the relevant clinical health data associated with the requested medical device. In this manner, the tool can output all of the relevant clinical health data in the corpus that relate to the requested medical device, as further described below.

[0043] In some aspects, the tool of the present disclosure can generate a summary of the relevant clinical health data that can be output to the user 125 in response to the search request. The summary can identify the number of certain features in the relevant clinical health data such that the user 125 can determine whether sufficient relevant records exist in the corpus for whatever purpose the user intends to utilize the records. For example only, the summary can include one or more of the number of: (i) electronic health records, (ii) health provider visits, (ill) diagnoses, or (iv) procedures are present in the relevant clinical health data. In some aspects, additional features can be included in the summary, such as the number of medications, the number of allergies, and/or indications of where the medical devices is used (that is, a location in the anatomy of the patients). The tool may also include one or more selectable elements that permit the user to filter the relevant clinical health data based on various features of the electronic health records.

[0044] In addition to the gathering, ingesting, and providing search functionality described above, in some implementations of the present disclosure the tool can also provide an automated categorization of the patients represented in the relevant clinical health data in order to assist in the curation and/or validation process. A machine learning algorithm can be utilized to group patients in the categories, which can then be associated with the electronic health records by generating a patient record corresponding to each patient. The patient record can include any portion of the ingested electronic health records, as well as the determined categories, associated with each patient. These categories can include, e.g., a safety category, a clinical benefit category, a performance category, and an unassigned category, as more fully discussed below.

[0045] The tool can also provide a graphical user interface (“GUI”) to a user. The GUI can be used to display the patient records to the user for validation. For example only, the user can review the information in a patient record and provide feedback as to whether the automated grouping of the associated patient is accurate by approving or rejecting each assigned category. The relevant clinical health data can be updated based on these validation inputs. In some aspects, updating the relevant clinical health data can include removing certain patients from the population of patients having relevant records (labeling them as not being relevant or the like). The validation feedback can also be used to adapt the machine learning algorithm to more accurately group patients in the categories for future classification tasks.

[0046] In addition to the above, in some aspects the tool can provide a surfacing functionality that determines and accentuates certain aspects of the patient records to provide the user with the most relevant information when validating patient records. For example only, artificial intelligence can be used to analyze each electronic health record to determine the relevance of each portion/feature therein to the user’s search request. A relevance score can be generated and the portions can be ranked based on their determined relevance. One or more of these portions can be surfaced, emphasized, or otherwise accentuated based on the ranking. In some implementations, the artificial intelligence can also or alternatively generate a summary of the most relevant portion(s) of each electronic health record and the summary can be included therein. In this manner, when a user begins reviewing a patient record, the most relevant portions and/or a summary thereof may be easily identified and reviewed by the user. This may be particularly useful for electronic health records that are lengthy (contain extensive notes, relate to a large number of healthcare provider visits or procedures, etc.).

[0047] The clinical health data can be continuously updated in real-time as new data is received. Such new data can include additional electronic health records (relating to “new” patients not present in the previous data) and/or additional information corresponding to a previously received electronic health record. Such additional information can correspond to a “new” or otherwise previously unknown health provider visit by a known patient. In this manner, the tool be used to provide an automated and real-time monitor of electronic health records pertaining to medical devices. For example only, the tool can automatically analyze the updated corpus of clinical health data to determine whether an event of interest has occurred. Events of interest include, but are not limited to, adverse events (medical device malfunction or failure, unexpected side effects, etc.) and off-label use (using a pharmaceutical or other medical device in an unapproved manner). In some aspects, a machine learning algorithm can be utilized to analyze the updated corpus of clinical health data to detect such events of interest. In alternative or additional aspects, other forms of machine analysis can be utilized to detect an event of interest (a rule-based analysis, etc.).

[0048] Referring now to FIGs. 3-11 , examples of various screenshots of a GUI associated with the clinical health data tool of the present disclosure is shown. These screenshots can be provided by the healthcare provider computing device(s) 110 to be displayed to a user 125 via the user computing device 120. Via the GUI, the user 125 can interact with the healthcare provider computing device(s) 110 to access the clinical health data curated by the tool, create and monitor various projects, and the like. FIG. 3 illustrates a homepage 300 presented to the user 125 upon logging into the tool. The homepage 300 comprises a search interface that permits a user 125 to select an existing project associated with a specific medical device, or start a new project, via one or more selectable elements 310. It should be appreciated that the selectable elements 310 can take any form, such as radio buttons, hyperlinks, clickable buttons, dropdown menus, or the like. Each project can be associated with one or more medical devices 320. The homepage 300 can permit the user 125 to submit a search query that identifies the medical device 320 of interest to the user 125.

[0049] With specific reference to FIGs. 4-7, upon creation of a new project or selection of an existing project, the user 125 can be presented with an initial data visualization screen 400. The tool can generate a summary 410 of the clinical health data that is relevant to the search query/project of interest to the user 125, which can be displayed via data visualization screen 400. The summary 410 can include, for example, a number of electronic health records 412 in the relevant clinical health data, a number of health provider visits 414 in the relevant clinical health data, and a number of health provider notes 416 in the relevant clinical health data. In some aspects, the summary can alternatively or additionally include a number of diagnoses in the relevant clinical health data, a number of procedures in the relevant clinical health data, a number of medications corresponding to the patient subpopulation in the relevant clinical health data, a number of allergies corresponding to the patient subpopulation in the relevant clinical health data, an indication of where the medical device is used, and/or any other information or features of possible interest to the user 125. The user 125 may be able to configure (through the settings of the tool) what information or features are displayed in the initial data visualization screen 400.

[0050] The user 125 can interact with the tool via the data visualization screen 400 in order to refine or filter the search request, as well as access the patient records (as further discussed herein). As shown in FIG. 4, one or more selectable elements 420 (such as those described above) can permit the user 125 to submit filtering criteria for the patient records. As shown in FIGs. 5-7, in some aspects the user 125 can filter the patient records based on patient data (FIG. 5), diagnosis data (FIG. 6), and/or procedure data (FIG. 7). In additional or alternative aspects, the user 125 can filter the patient records based on the healthcare provider notes and/or any other information or features of possible interest to the user 125. Example features of the patient data can include, but are not limited to, demographic data of the particular patient, such as a sex, an age, an ethnicity, and/or a race of the particular patient. The diagnosis data can include diagnosis codes or any other differentiating criteria related to a patient diagnosis (via a keyword or other text search, etc.). Similarly, the procedure data can include procedure codes or any other differentiating criteria related to a procedure of a patient. Although not specifically illustrated, it should be appreciated that any other feature or aspect of the patient records can be used as a filtering criterion. [0051] As mentioned above, the tool can automatically categorize patients represented in the relevant clinical health data in order to assist in a curation and/or validation process of the clinical health data. A machine learning algorithm, e.g., can be utilized to group patients in various categories, which can then be associated with the electronic health records by generating a patient record 800 corresponding to each patient. As shown in FIG. 8, the patient record 800 can be displayed to the user 125 and can include any portion of the ingested electronic health records. In FIG. 8, the illustrated example patient record 800 includes patient data 810, procedure data 820, a listing 830 of the various different visits, diagnoses, procedures, etc. of the patient record 800, and a categorization section 840 for the patient. Although not specifically illustrated, the patient record 800 can also include outcome data associated with the patient, where the outcome data can be input as free form input and/or as a selection from a list of options (e.g., success, failure, undetermined).

[0052] The categorization section 840 can be configured to display the categories to which the patient belongs. In the illustrated example, the categories shown are “Safety” (842), “Clinical Benefit” (842), and “Performance” (846). It should be appreciated that other categories are within the scope of the present disclosure. Further, in some aspects, an “undetermined” or “unassigned” category can be included when the patient is not assigned to any specific category, which can be explicitly displayed or merely inferred by not displaying any of the other categories. The user 125 can navigate the displayed patient record 800 to expand, contract, remove, add, drill down into, and/or change the various sections or features in the patient record 800 as desired. For example only, and as shown in FIG. 9, the user 125 can interact with the patient record 800 such that a health provider notes section 850 is displayed.

[0053] The user 125 can review the patient record 800 during a manual validation process. The validation process can be used to correct, confirm, validate, etc. the automatic categorization process performed by the tool. In some implementations, the patient record 800 can generated, configured, or otherwise arranged by the tool to assist the user 125 with the manual validation process. The tool may utilize artificial intelligence to analyze the data in a patient record 800 to determine a relevance of each portion of the record to the search request of the user 125. The relevance of the portions of the record to the search query may be determined by quantifying or otherwise measuring the contribution of each portion of the patient record 800 to the categorization of the of the patient. The tool may also rank the portions of the patient record 800 based on their determined relevance, and accentuate one or more portions in the patient record 800 based on the ranking. The tool may accentuate one or more portions of the patient record 800 by highlighting, bolding, italicizing, or otherwise visually differentiating the highly relevant portions of the patient record 800 in order to draw the attention of the user 125 to these portions. In some aspects, the tool may also or alternatively accentuate the one or more portions of the patient record 800 by utilizing artificial intelligence to generate a summary of the highly relevant one or more portions and including that summary within the patient record.

[0054] As shown in FIG. 10, the user 125 can access a categorization menu 1000, e.g., by selecting a selectable element 1010. In the illustrated example, the categorization menu 1000 comprises a drop down menu that permits the user 125 to enter, correct, validate, etc. the appropriate category/categories (and even subcategories) for the patient. In this manner, the user 125 can provide a validation input for each patient record 800 via the categorization menu 1000. In some aspects, the validation input can correspond to a manual approval or manual rejection of the categories automatically assigned to the patient by the tool.

[0055] Furthermore, and as shown in FIG. 11 , the user 125 can select a selectable element 1110 to open up a labeling menu 1100. Labeling menu 1100 can permit the user 125 to mark or label the patient corresponding to the displayed patient record 800 as being included or excluded from the relevant clinical health data. In some aspects, a third option of “undetermined” can also be selected by the user 125 to flag the patient/patient record 800 for additional review. While being illustrated and described separately from the categorization menu 1000, it should be appreciated that the options presented in the labeling menu 1100 can also be considered categories that the tool may automatically assign to the patient record. In this manner, the user 125 can also utilize the labeling menu 1100 to validate a patient record to update the relevant clinical health data associated with the search request. For example only, a patient can be marked as “excluded” and thereby be removed from the relevant clinical health data. One skilled in the art will understand that “removal” of a patient record from the relevant clinical health data may not delete the patient record 800 from the corpus of health data, but instead merely exclude the patient record 800 from results that are deemed relevant to the search request.

[0056] Referring now to FIG. 12, a computer-implemented method 1200 for managing, storing, organizing, and/or classifying clinical health data associated with medical devices is disclosed. As mentioned above, method 1200 will be described as being performed by a healthcare provider computing device 110 for the sake of simplicity. At 1210, the healthcare provider computing device 110 will receive a plurality of electronic health records associated with one or more medical devices and a patient population. Each of the plurality of electronic health records can be associated with a particular patient and include one or more of the following: (i) patient data regarding the particular patient, (ii) medical device data identifying and corresponding to a particular medical device of the particular patient, (iii) diagnosis data corresponding to a particular diagnosis of the particular patient, (iv) procedure data corresponding to a particular procedure of the particular patient, (v) healthcare provider notes regarding the particular patient; or (vi) outcome data corresponding to a particular outcome associated with the particular patient. [0057] The healthcare provider computing device 110 can ingest (1220) the plurality of electronic health records at 1220. The ingestion 1220 can include normalizing 1225 at least one of the patient data, the medical device data, the diagnosis data, the procedure data, or the healthcare provider notes for the patient population by utilizing artificial intelligence to identify commonalities among different features in the plurality of electronic health records. In some aspects, the healthcare provider notes can include unstructured text and the normalization 1225 can include, at 1227, utilizing a natural language processing algorithm to process the unstructured text to identify the commonalities between the healthcare provider notes in the plurality of electronic health records.

[0058] At 1230, the ingested plurality of electronic health records can be indexed to obtain a corpus of clinical health data associated with the one or more medical devices. The corpus of clinical health data can comprise a searchable database of the clinical health data, which can be stored, e.g., in one or more electronic memory devices 115. Further, the commonalities identified during normalization 1225 can be linked in the corpus of clinical health data such that the different features are grouped together. A search interface for the searchable database of the clinical health data can be provided (at 1240) to a user computing device 120 associated with a user 125. A search request for relevant clinical health data associated with a requested medical device of the one or more medical devices can be received (at 1250) at the healthcare provider computing device 110 from the user computing device 120 via the search interface. The search request can identify the requested medical device, as well as any other features of interest to the user 125. The relevant clinical health data associated with the requested medical device can be retrieved (at 1260) and output (at 1270) to the user computing device 120. The relevant clinical health data can correspond to a patient subpopulation of the patient population. [0059] Referring now to FIG. 13, another computer-implemented method 1300 for managing, storing, organizing, and/or classifying clinical health data associated with medical devices is disclosed. Method 1300 can be performed in conjunction with method 1200 discussed above. More specifically, method 1300 can be performed to provide a validation process associated with the retrieval (1260) and outputting (1270) of method 1200. At 1310, the healthcare provider computing device 110 can automatically categorize the patients in the patient subpopulation identified at 1260. More specifically, each patient in the patient subpopulation can be grouped into one or more categories of a plurality of categories based on their corresponding electronic health record and a machine learning algorithm, as discussed above.

[0060] At 1320, a patient record for each patient in the patient subpopulation can be generated. Each patient record can include the one or more categories in which its corresponding patient is grouped at 1310. In some aspects, the patient record can be generated to assist the user 125 in validating the groupings. For example only, at 1322, the electronic health records can be analyzed to determine a relevance of each portion of the electronic health record to the search request. At 1324, the portions of the electronic health record can be ranked based on their determined relevance. One or more portions in the electronic health record can then be accentuated (1326) based on the ranking (1324). In this manner, the user 125 can be visually or otherwise directed to the most relevant portions of the electronic health records upon accessing a patient record. Furthermore, in some aspects, accentuating the electronic health records can include utilizing artificial intelligence to generate a summary of the one or more relevant portions, which can be included in the electronic health record for the patient.

[0061] At 1330, the user 125 can provide a validation input based on the electronic health record of a patient. In response thereto, the relevant clinical health data associated with the requested medical device can be updated (at 1340) based on the validation inputs. The updated clinical health data can be stored at 1350. In some implementations, at 1360, the machine learning algorithm used to categorize the patient at 1310 can be adapted based on the feedback received from the validation process results. In this manner, the machine learning algorithm can be improved during use in either a passive or active adaptation scheme.

[0062] Referring now to FIG. 14, a computer-implemented method 1400 of detecting and outputting events of interest associated with medical devices is disclosed. Method 1400 can be performed in conjunction with either or both of methods 1200 and 1300. discussed above. More specifically, method 1400 relates to the continuous monitoring of the relevant clinical health data related to medical devices generated by method 1200. At 1410, the corpus of clinical health data can be updated based on newly received information/data. The new data can be one or more additional electronic health records, or additional information corresponding to a previously received electronic health record. The updated corpus can be automatically and continuously analyzed (at 1420) to determine whether an event of interest has occurred and, when an event of interest occurs, an alert can be output (at 1430). An event of interest can correspond to an adverse event, an off-label use, or any other change in the performance, functionality, or outcome associated with the one or more medical devices. In some implementations, the analysis at 1420 comprises utilizing a machine learning algorithm (1425) to detect the event of interest. The machine learning algorithm can be any form of artificial intelligence, such as a classification algorithm, a clustering algorithm, or a neural network process.

[0063] Example embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well- known procedures, well-known device structures, and well-known technologies are not described in detail.

[0064] The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "and/or" includes any and all combinations of one or more of the associated listed items. The terms "comprises," “comprising," "including," and "having," are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed. [0065] Although the terms first, second, third, etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms may be only used to distinguish one element component, region, layer or section from another region, layer or section. Terms such as “first," “second," and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first element, component, region, layer or section discussed below could be termed a second element, component, region, layer or section without departing from the teachings of the example embodiments.

[0066] As used herein, the term module may refer to, be part of, or include: an Application Specific Integrated Circuit (ASIC); an electronic circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor or a distributed network of processors (shared, dedicated, or grouped) and storage in networked clusters or datacenters that executes code or a process; other suitable components that provide the described functionality; or a combination of some or all of the above, such as in a system- on-chip. The term module may also include memory (shared, dedicated, or grouped) that stores code executed by the one or more processors.

[0067] The term code, as used above, may include software, firmware, byte-code and/or microcode, and may refer to programs, routines, functions, classes, and/or objects. The term shared, as used above, means that some or ail code from multiple modules may be executed using a single (shared) processor. In addition, some or all code from multiple modules may be stored by a single (shared) memory. The term group, as used above, means that some or ail code from a single module may be executed using a group of processors, in addition, some or all code from a single module may be stored using a group of memories.

[0068] The techniques described herein may be implemented by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions that are stored on a non-transitory tangible computer readable medium. The computer programs may also include stored data. Nonlimiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.

[0069] Some portions of the above description present the techniques described herein in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times to refer to these arrangements of operations as modules or by functional names, without loss of generality.

[0070] Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0071] Certain aspects of the described techniques include process steps and instructions described herein in the form of an algorithm. It should be noted that the described process steps and instructions could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.

[0072] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed forth© required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer. Such a computer program may be stored in a tangible computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0073] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatuses to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the art, along with equivalent variations. In addition, the present disclosure is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein, and any references to specific languages are provided for disclosure of enablement and best mode of the present invention.

[0074] The present disclosure is well suited to a wide variety of computer network systems over numerous topologies. Within this field, the configuration and management of large networks comprise storage devices and computers that are communicatively coupled to dissimilar computers and storage devices over a network, such as the Internet.

[0075] The foregoing description of the embodiments has been provided for purposes of illustration and description, it is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.

Claims

CLAIMS What is claimed is:

1. A computer-implemented method for managing, storing, organizing, and/or classifying clinical health data associated with medical devices, comprising: receiving, at a healthcare provider computing device, a plurality of electronic health records associated with one or more medical devices and a patient population, each of the plurality of electronic health records being associated with a particular patient and comprising: (i) patient data regarding the particular patient, (ii) medical device data identifying and corresponding to a particular medical device of the particular patient, (iii) diagnosis data corresponding to a particular diagnosis of the particular patient, (iv) procedure data corresponding to a particular procedure of the particular patient, (v) healthcare provider notes regarding the particular patient; and (vi) outcome data corresponding to a particular outcome associated with the particular patient; ingesting, at the healthcare provider computing device, the plurality of electronic health records by normalizing at least one of the patient data, the medical device data, the diagnosis data, or the procedure data for the patient population, wherein normalizing comprises utilizing artificial intelligence to identify commonalities among different features in the plurality of electronic health records; indexing, at the healthcare provider computing device, the ingested plurality of electronic health records to obtain a corpus of clinical health data associated with the one or more medical devices, the corpus of clinical health data comprising a searchable database of the clinical health data, wherein the identified commonalities are linked in the corpus of clinical health data such that the different features are grouped together; providing, from the healthcare provider computing device, a search interface for the searchable database of the clinical health data to a user computing device associated with a user; receiving, at the healthcare provider computing device and from the user computing device via the search interface, a search request for relevant clinical health data associated with a requested medical device of the one or more medical devices, the search request identifying the requested medical device; retrieving, at the healthcare provider computing device, the relevant clinical health data associated with the requested medical device, the relevant clinical health data corresponding to a patient subpopulation of the patient population; and outputting, from the healthcare provider computing device and to the user computing device, the relevant clinical health data associated with the requested medical device.

2. The computer-implemented method of claim 1 , wherein the patient data comprises demographic data of the particular patient, the demographic data including at least one of a sex, an age, an ethnicity, or a race of the particular patient.

3. The computer-implemented method of claim 1 , wherein outputting the relevant clinical health data associated with the requested medical device comprises: generating a summary of the relevant clinical health data; and providing a graphical user interface (“GUI”) to the user computing device, wherein the GUI includes the summary of the relevant clinical health data and one or more selectable elements for further refining the relevant clinical health data.

4. The computer-implemented method of claim 3, wherein the summary includes: a number of electronic health records in the relevant clinical health data; a number of health provider visits in the relevant clinical health data; a number of diagnoses in the relevant clinical health data; and a number of procedures in the relevant clinical health data.

5. The computer-implemented method of claim 4, wherein the summary further includes: a number of medications corresponding to the patient subpopulation in the relevant clinical health data; a number of allergies corresponding to the patient subpopulation in the relevant clinical health data; and an indication of where the medical device is used.

6. The computer-implemented method of claim 3, wherein the one or more selectable elements for further refining the relevant clinical health data is configured to filter the relevant clinical health data based on at least one of the patient data, the diagnosis data, the procedure data, or the healthcare provider notes.

7. The computer-implemented method of claim 1, further comprising: grouping, at the healthcare provider computing device and utilizing a machine learning algorithm, each patient in the patient subpopulation into one or more categories of a plurality of categories based on their corresponding electronic health record; and generating, at the healthcare provider computing device, a patient record for each patient in the patient subpopulation, each patient record including the one or more categories in which its corresponding patient is grouped, wherein outputting the relevant clinical health data associated with the requested medical device comprises providing a graphical user interface (“GUI”) configured to display the patient records.

8. The computer-implemented method of claim 7, wherein each patient record further includes: (I) the patient data, (ii) the diagnosis data, (iii) the procedure data, (iv) the healthcare provider notes of its corresponding patient, and (v) the outcome data.

9. The computer-implemented method of claim 8, further comprising: receiving, at the healthcare provider computing device and from the user computing device via the GUI, a validation input for each patient record, the validation input corresponding to a manual approval or a manual rejection of the one or more categories in which its associated patient is grouped.

10. The computer-implemented method of claim 9, further comprising: updating, at the healthcare provider computing device, the relevant clinical health data associated with the requested medical device based on the validation inputs.

11. The computer-implemented method of claim 10, wherein updating the relevant clinical health data comprises removing certain patients from the patient subpopulation.

12. The computer-implemented method of claim 9, further comprising adapting the machine learning algorithm based on the validation inputs.

13. The computer-implemented method of claim 8, wherein generating the patient record for each patient comprises utilizing the artificial intelligence to: (i) analyze the electronic health record for the corresponding patient to determine a relevance of each portion of the electronic health record to the search request (ii) rank the portions of the electronic health record based on their determined relevance, and (iii) accentuate one or more portions in the electronic health record based on the ranking.

14. The computer-implemented method of claim 13, wherein accentuating the one or more portions in the electronic health record based on the ranking comprises utilizing the artificial intelligence to generate a summary of the one or more portions, wherein the summary is included in the electronic health record.

15. The computer-implemented method of claim 7, wherein the plurality of categories includes a safety category, a clinical benefit category, a performance category, and an unassigned category.

16. The computer-implemented method of claim 1, further comprising updating, at the healthcare provider computing device, the corpus of clinical health data in real time based on receiving: (i) one or more additional electronic health records, or (ii) additional information corresponding to a previously received electronic health record.

17. The computer-implemented method of claim 16, wherein the additional information corresponds to a previously unknown health provider visit.

18. The computer-implemented method of claim 16, further comprising: automatically analyzing, at the healthcare provider computing device, the updated corpus of clinical health data to determine whether an event of interest has occurred; and outputting, from the healthcare provider computing device, an alert when the event of interest has occurred.

19. The computer-implemented method of claim 18, wherein the event of interest corresponds to an adverse event or off-label use associated with the one or more medical devices.

20. The computer-implemented method of claim 18, wherein automatically analyzing the updated corpus of clinical health data to determine whether the event of interest has occurred comprises utilizing a machine learning algorithm to detect the event of interest.

21. The computer-implemented method of claim 18, wherein the machine learning algorithm comprises a classification algorithm, a clustering algorithm, or a neural network process.

22. The computer-implemented method of claim 1 , wherein the healthcare provider notes include unstructured text, and wherein utilizing artificial intelligence to identify commonalities among different features in the plurality of electronic health records comprises utilizing a natural language processing algorithm to process the unstructured text to identify the commonalities between the healthcare provider notes in the plurality of electronic health records.