Optimizing Instrument Selection

Abstract

In various embodiments, a process for optimizing instrument selection comprises receiving an inventory of surgical instruments available for use during a surgical procedure, receiving images depicting at least some of the available surgical instruments used during the surgical procedure, and at least partially automatically generating a record of the used surgical instruments depicted in the images. The process comprises storing the records in a data storage of surgical instrument usage data, and automatically analyzing the records stored in the data storage of surgical instrument usage data to identify one or more surgical instrument readiness groupings that optimize one or more specified usage metrics.

Description

CROSS-REFERENCE TO OTHER APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 441,560, filed January 27, 2023, entitled "INSTRUMENT SELECTION OPTIMIZATION," which is incorporated herein by reference for all purposes. [Background technology]

[0002] Surgical procedures (or, more generally, medical procedures) are typically performed by medical personnel (e.g., surgeons) using surgical tools (e.g., instruments) prepared and arranged on surgical trays for utilization during the medical procedure / surgery. The selection of tools and / or the configuration of the surgical tray impacts the cost, duration, and efficiency with which the procedure is performed, affecting the overall profitability of the hospital. Surgical tool utilization varies depending on the surgeon and the surgical procedure being performed. In one aspect, tools not utilized during the procedure are processed for reuse after each procedure and repaired after a certain number of reprocessing cycles, which requires additional cost and time. Other problems from overloaded trays include increased operating room (OR) turnover times, prolonged surgical procedure times, and increased case delays due to SPD-related issues. In another aspect, tools tend to be added to existing trays, and as new procedures and techniques are added, additional trays containing new tools may be added over time, leading to increased waste. Therefore, optimized tool selection is needed. [Brief explanation of the drawings]

[0003] Various embodiments of the present invention are disclosed in the following detailed description and the accompanying drawings.

[0004] [Figure 1] 1 is a flow chart illustrating one embodiment of a process for optimizing instrument selection.

[0005] [Figure 2]FIG. 1 is a block diagram illustrating one embodiment of a system for optimizing instrument selection.

[0006] [Figure 3A] FIG. 10 illustrates an example of a user interface for optimizing instrument selection.

[0007] [Figure 3B] FIG. 10 illustrates an example of a user interface for optimizing instrument selection including tray analysis.

[0008] [Figure 3C] FIG. 10 illustrates an example of a user interface for optimizing instrument selection including optimization information for a particular tray.

[0009] [Figure 3D] FIG. 10 illustrates an example of a user interface for optimizing instrument selection including unused instruments.

[0010] [Figure 3E] FIG. 10 illustrates an example user interface for optimizing instrument selection, including optimization for a specific tray.

[0011] [Figure 4] FIG. 10 illustrates an example of a user interface for an annotation engine.

[0012] [Figure 5A] FIG. 10 is a diagram showing an example of a report including a procedure manual.

[0013] [Figure 5B] FIG. 10 is a diagram showing an example of a report including a procedure manual.

[0014] [Figure 6] 10 illustrates an example report including a tray compliance roadmap. In various embodiments, the roadmap can be used to adhere to tray weight limits and reduce workplace injuries.

[0015] [Figure 7] 10 shows an example of a report that includes procedural financial insights. The insights can help establish best practices and generate a surgeon's report card.

[0016] [Figure 8A] An example of a report that includes service line optimization.

[0017] [Figure 8B] An example of a report that includes service line optimization.

[0018] [Figure 8C] An example of a report that includes service line optimization.

[0019] [Figure 8D] An example of a report that includes service line optimization.

[0020] [Figure 9] FIG. 1 is a functional diagram illustrating a computer system programmed for instrument selection optimization, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0021] The present invention may be embodied in various forms, including as a process, an apparatus, a system, a composition of matter, a computer program product embodied on a computer-readable storage medium, and / or a processor configured to execute instructions stored in and / or provided by a memory coupled to the processor. These embodiments, or any other form the present invention may take, may be referred to herein as technology. In general, the order of steps in a disclosed process may be varied within the scope of the present invention. Unless otherwise noted, components, such as a processor or memory, described as configured to perform a task may be implemented as general components temporarily configured to perform the task at a given time, or as specific components manufactured to perform the task. As used herein, the term “processor” refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0022] The following is a detailed description of one or more embodiments of the present invention with reference to figures that illustrate the principles of the invention. While the present invention has been described in connection with such embodiments, it is not limited to any particular embodiment. The scope of the present invention is limited only by the claims, and the present invention includes many alternatives, modifications, and equivalents. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. These details are for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For simplicity, technical matters that are well known in the art related to the present invention have not been described in detail so as not to unnecessarily obscure the present invention.

[0023] It has been observed that during the majority of medical procedures, many tools are inconsistently utilized, overlapped across multiple trays in the same surgical procedure, and presented in an inefficient manner, leading to waste, among other factors. Utilization rates can vary depending on factors such as the particular surgeon performing the procedure, the type of surgery, the complexity of the case, and the patient's health. The disclosed technology determines and optimizes tool selection. For example, surgical trays (tool groupings) may be automatically / programmatically determined to optimize term selection and utilization. In various embodiments, instruments (or more generally, any items of inventory related to a medical procedure, such as tools or soft objects like sponges or sutures) can be selected for placement on surgical trays. Given sufficient data, optimal selections can be automatically / programmatically determined. One or more groups of tools (e.g., groups corresponding to surgical trays) can be formed, with each tray containing one or more tools. The optimized tray configuration can be output, for example, in a report.

[0024] The disclosed technology has application in a variety of contexts, and although primarily described using the example of surgical instruments, the disclosed technology may be applied to a variety of tools, such as other inventory used in surgery, medical procedures, or other processes.

[0025] 1 is a flow chart illustrating one embodiment of a process for instrument selection optimization, which may be implemented in or performed by an instrument selection optimization system (such as system 250 shown in FIG. 2) or a processor (such as processor 902) shown in FIG.

[0026] In the illustrated example, the process begins by receiving a description of surgical tools available for use during a surgical procedure (step 100). The description of surgical tools available for use during a surgical procedure includes an inventory of surgical tools that may be used during the procedure. The description may vary from surgeon to surgeon, hospital to hospital, and healthcare system to healthcare system.

[0027] An example of an inventory of surgical tools available for use during a surgical procedure is an instrument count sheet. The instrument count sheet contains the material inventory for a particular surgical tray configuration, which may be surgeon-specific. The instrument count sheet is exportable to multiple formats, for example, via CSV, PDF, Excel file, or from a handwritten document. The format of the instrument count sheet may vary across sources and sites of care (e.g., hospital, ambulatory surgery center, or supplier-owned surgical trays).

[0028] The process receives an image showing at least some of the available surgical tools used during the surgical procedure (step 102). The image may include a visual representation showing the shape / configuration of the tools. The tools may be provided in a tray. For example, the image includes a photograph of a surgical tray. The photograph may include one or more surgical trays containing one or more instruments. The image may be captured by any device with a camera with an appropriate megapixel rating (such as a smartphone). The image may be captured by a technician or other user after the tools have been used (e.g., at the end of a medical procedure).

[0029] In various embodiments, the image includes only used (e.g., opened) instruments. Unused instruments are obscured, for example, by being placed under a cloth or otherwise removed from the camera's view. Alternatively, the image may include a mix of used and unused instruments, with subsequent image processing classifying the used and unused instruments.

[0030] The images may be accompanied by metadata, for example, the user who captured the image may indicate what type of tray or contents are in the image, or the user may not need to provide any information at all, and the information may be determined automatically when processing the image, as described further herein.

[0031] The process at least partially automatically generates a record of the surgical tools used shown in the image (step 104). The record may include an identification of the type or other characteristics of the surgical tools used shown in the image. For example, the surgical tools may be labeled using image recognition, manual annotation, machine learning annotation, etc.

[0032] In various embodiments, automatically generating a record of the surgical instruments used in the images includes annotating each of at least a portion of the surgical instruments based at least on a plurality of previously received images. For example, an annotation engine is used to automatically / programmatically generate a set of known data to identify instruments used in a surgery from a particular surgical tray. The identification may be based on the image and / or on instrument classification, as further described herein.

[0033] The annotation engine may comprise a trained machine learning model, solicit input from a human annotator, or be a hybrid of both. The annotation engine may comprise a machine learning model that utilizes data from human annotators and / or a separate trained dataset collected from thousands of images of instruments to learn how to collaborate with the annotators to automatically and accurately identify instruments. An example of an annotation engine is the instrument classification engine 252, which is further described with respect to FIG. 2. A user interface for the human annotator may be provided via a user portal 256. An example of a user interface for the annotation engine is shown in FIG. 4.

[0034] To obtain a statistically significant number of images, data may be aggregated across one or more procedures. For example, data is continuously captured about instrument utilization from a particular surgical tray until a statistically significant sample size is achieved. A robustness analysis algorithm is used to determine when a statistically significant sample size has been collected.

[0035] In various embodiments, the total number of previously received images used for annotation is based at least on a robustness analysis of the previously received images performed using a threshold indicating the reliability of the previously received images. For example, the process performs the robustness analysis, such as by randomly subsampling from a set of images. Assume there are 50 photos of a particular tray. The robustness analysis determines how reliable the results are if only a portion of the photos are used (e.g., if only 40, 35, or 20 photos are used). Identifying the minimum subset size for which the results are sufficiently reliable reduces processing resources utilized and avoids machine learning models associated with overfitting.

[0036] In various embodiments, the total number of previously received images utilized for annotation is based at least on a coverage analysis of the previously received images performed using a threshold indicating a level of representativeness of the surgical procedure with respect to the group of surgical procedures. The level of representativeness is a quantification indicating whether the surgical procedure (e.g., a particular surgical procedure) is sufficiently representative when considering the group of surgical procedures. The coverage analysis may answer questions such as: Is there sufficient representation of a particular surgeon whose team tends not to provide input (e.g., not capture images or otherwise participate in providing input data), or is there sufficient representativeness of this surgical procedure? A visualization of the robustness analysis and / or coverage analysis may be generated and output via a user interface, such as the user portal 256.

[0037] In various embodiments, automatically generating a record of the used surgical instruments shown in the image includes identifying each of at least some of the used surgical instruments without using a description of the surgical instruments available for use during the surgical procedure. Alternatively, the record of the used surgical instruments shown in the image is based at least on a description of the surgical instruments available for use during the surgical procedure. For example, the surgical instruments shown in the image are categorized using the description of the surgical instruments available for use during the surgical procedure received in step 100. The image may include instruments that are not in the description of the surgical instruments (perhaps from another tray or disposable peel pack). These instruments may also be annotated.

[0038] As described further herein, metadata may be collected with or identified from the images, for example, manufacturer / supplier data may be detected and analyzed to provide market insights and analysis.

[0039] The process stores the records in a data storage of surgical tool usage data (step 106). The records may be stored and retrieved from the data storage for analysis. With brief reference to FIG. 2, the records may be stored in record store 264. For example, once a statistically significant sample size (e.g., images) is reached, data is collected and stored. With reference to FIG. 1, the collected data may be used by the process to interpret actual instrument usage data. The records may be used to optimize one or more specified usage metrics by identifying surgical tool readiness groupings as follows:

[0040] The process automatically analyzes records stored in the data storage of surgical tool usage data to identify one or more surgical tool readiness groupings that optimize one or more specified usage metrics (step 108). The records may be collected / analyzed (e.g., by a data science team or programmatically / automatically) to determine metrics such as utilization rates corresponding to each instrument. In various embodiments, suggestions on how to optimize trays, service lines, complete inventory, etc. may be determined and provided.

[0041] In various embodiments, the automated analysis includes performing a tray analysis. A tray analysis is an analysis related to the configuration of instruments on a tray (also referred to as a "tray configuration"). Optimizations may be identified for how to optimize a particular tray configuration, such as which instruments to include in a particular tray. For example, one or more surgical tool preparation groupings are organized into one or more trays. The one or more trays include a main tray containing a first subset of used surgical tools and an auxiliary tray containing a second subset of used surgical tools. Optimizations may be determined for how to optimize multiple trays used in a procedure. Instruments may be categorized by ownership (hospital-owned vs. (contracted) supplier-owned, etc.). Supplier-owned trays may be optimized separately from hospital-owned trays, for example.

[0042] In various embodiments, the automated analysis includes determining a co-use pattern of a first one or more surgical tools used with a second one or more surgical tools with a frequency that meets a usage threshold. A co-use pattern refers to tools that tend to be used together or that tend not to be used together. Identifying a co-use pattern allows for various optimization suggestions to be made. For example, a co-use pattern may allow for the division of a single tray into two trays: a primary tray (used together) and a non-primary ("auxiliary") tray (used less frequently and not used with each other).

[0043] In various embodiments, the automated analysis includes performing a service line analysis. That is, the automated analysis includes identifying optimizations for the (full) service line inventory of trays present at a hospital. This can help standardize procedures across hospitals within a particular system. For example, if a health network acquires a new hospital, optimization options may exist. A user of the instrument selection optimization system may indicate desired parameters (such as the optimal number of trays) when factoring in the addition of a new hospital. Best practices may be suggested or adjusted accordingly.

[0044] The one or more specified usage metrics include at least one of a utilization rate for a specific instrument, a utilization rate for a specific surgeon, and / or a utilization rate for a specific procedure. In various embodiments, the usage metrics may be specified and adjusted via an application programming interface (API) and / or a user interface. For example, a constraint (such as the number of peel packs per surgeon) is presented on a dashboard as a slider. A user can adjust the slider to provide input, which causes the process to include / update the metric and determine an optimization that takes this into account. As another example, a user may query an optimization for a specific number of surgeons, a specific number of procedures, how many trays a service line has as a function of the number of procedures, etc. As yet another example, a user may state, "I want 20 to 30 instruments. What are the estimated costs / benefits from the best version of each of those options?"

[0045] In various embodiments, the automated analysis includes performing a robustness analysis to determine the reliability of the identified surgical tool preparation grouping(s). The robustness analysis is the same as the example described with respect to step 104, unless otherwise noted herein. The robustness analysis refers to determining the amount of data necessary to reach statistical significance. A minimum subsample size is determined, where utilizing the minimum subsample size results in performance meeting a threshold (e.g., reaching a sufficient level of confidence).

[0046] In various embodiments, the automated analysis includes performing a coverage analysis to determine the representativeness level of features associated with the surgical procedure. The coverage analysis is the same as the example described with respect to step 104 unless otherwise noted herein. The coverage analysis refers to determining gaps in the data used for the analysis. For example, whether a particular surgeon or procedure is sufficiently representative in the data to obtain results applicable to the particular surgeon or procedure. The coverage analysis may be performed based at least on a description of the surgical tools available for use during the surgical procedure. The description of the surgical tools may be used to identify which tools are in short supply or in excess.

[0047] 2, the usage metrics may be specified by various users, such as the instrument selection optimization system 250, the schedule provider 220, the image provider 210 (e.g., a hospital providing input data), or others. For example, surgeon departures may be taken into account by removing corresponding data to allow this to be indicated during the coverage analysis phase.

[0048] Examples of optimizations include, but are not limited to: Removal of unused equipment, Creation of a main tray with the most used instruments, Reducing the number of instruments (e.g., reducing the number of instruments from 100 to 50, with the remaining 50 instruments provided in an auxiliary tray), · Estimated frequency of use / opening of the device; -Adjustment of auxiliary trays (number of auxiliary trays, etc.), Optimizing the size of the main tray (e.g., the number of instruments that should be included in the main tray), and Optimizing the set of instruments kept in the operating room to cater to all surgeons who use the room.

[0049] In various embodiments, the process outputs a report based at least on an automated analysis of records stored in the data storage of surgical tool usage data to identify one or more surgical tool preparation groupings that optimize one or more specified usage metrics, examples of which are further described with respect to Figures 5A-8D.

[0050] 2 is a block diagram illustrating one embodiment of a system for equipment selection optimization. The system includes an equipment selection optimization system 250, an image provider client device 210, an image store 232, a schedule provider client device 220, and a schedule store 234. Although illustrated as being external / remote to equipment selection optimization system 250, image store 232, schedule store 234, and record store 264 may instead be hosted locally by equipment selection optimization system 250. The data in stores 232, 234, and 264 may be stored by various devices or combinations of devices.

[0051] The image provider client device 210 is configured to capture and / or provide images depicting at least a portion of the available surgical tools used during a surgical procedure. The images may be processed utilizing the disclosed techniques (e.g., the processing of FIG. 1 ) to identify one or more surgical tool preparation groupings that optimize one or more specified usage metrics.

[0052] Image store 232 is configured to store images (such as images captured by image provider client device 210). Alternatively, images may be sent directly to equipment selection optimization system 250 without first being stored in image store 232. Image store 232 is communicatively coupled to image provider client device 210 and equipment selection optimization system 250.

[0053] The schedule provider client device 220 is configured to collect and provide an inventory of surgical tools available for use during a surgical procedure. The inventory of surgical tools is sometimes referred to as a "schedule." The schedule provider client device may include or be included in an electronic health record (EHR) system or an electronic medical record (EMR) system.

[0054] The schedule store 234 is configured to store a schedule or description of surgical tools available for use during a surgical procedure (such as collected by the schedule provider client device 220). The schedule store 234 is communicatively coupled to the image provider client device 210 and the instrument selection optimization system 250. As shown in this example, in various embodiments, the description of surgical tools 236 available for use during a surgical procedure is received from a first source (here, the image provider client device 210), and the images 230 depicting at least some of the available surgical tools used during the surgical procedure are received from a second source different from the first source (here, the schedule provider client device 220).

[0055] Client devices 210 and 220 may include any processing device, such as a mobile smartphone, tablet, computer, etc. An example of a processing device is further described herein with respect to FIG. 9. Client devices may be customized for instrument selection optimization (e.g., loaded with appropriate software applications programmed to perform the disclosed techniques). Device features (e.g., features that may adversely affect security or are unnecessary) may be disabled.

[0056] In various embodiments, a client device 210 resides in the operating room and takes photos for use by the data scientist. Images are captured on-site, for example, by a surgical technician. Metadata may be entered or otherwise associated with the images. Examples of metadata include the operating room, facility, surgeon, type of surgical procedure, etc. The images may be annotated (manually and / or machine) and then associated with surgical information. The surgical information may be provided asynchronously with the image capture. For example, the surgical information may be uploaded by the hospital periodically (such as weekly). The surgical information may be provided in various formats (such as a CSV or Excel file).

[0057] In various embodiments, the client device may be dynamically reconfigured. For example, the client device may be reconfigured based on the particular server environment. As another example, a tenant ID may be provided to accommodate a separate, single tenant. The user may provide input (such as a selection of a server, facility, or operating room), and the client device is configured to be appropriate for that environment. Tray options may vary by facility, and appropriate options are displayed. Adaptations are made to the capabilities, hardware, and software features of the client device.

[0058] The appliance selection optimization system 250 includes an appliance classification engine 252, an optimization engine 262, a schedule manager 254, a user portal 256, and an authentication engine 258. Other microservices provided by the system 250 are described and may be executed by any of these components, as needed.

[0059] The schedule manager 254 is configured to receive, verify, and otherwise manage surgical equipment specifications (also called schedules). In various embodiments, the schedule manager includes an upload service that obtains a CSV manifest with links to files and their associated metadata. Middleware may be provided to support the upload service. For example, the upload service may be accessed via an application programming interface (API) to obtain a link that allows data to be uploaded to a secure bucket, and the queue may be managed as needed. The schedule manager provides a mechanism for securely storing and accessing user reports and associated metadata. The schedule manager provides an endpoint for client devices 210 and 220 to securely upload images, schedules, or other data, provides the user portal 256 with the ability to search for them via metadata, allows census equipment to be stored and queried, and incorporates the centralized security of an authentication service.

[0060] In various embodiments, the schedule manager 254 schedules import files. For example, weekly surgical procedure information is retrieved from the EHR. It has been observed that schedule formats can change rapidly. The schedule format is adapted by performing one or more transformations that can be embedded in a dynamic manifest for each facility and stored outside of the code (e.g., stored in a database). The manifest provides recipes for converting different schedule import file formats for different customers into a common format. The manifest is advantageous compared to code because it can change on a shorter cycle than the code release cycle.

[0061] Surgical procedure information may be entered and validated via the UI. For example, a particular cell may expect data in a format with a list or array of trays or peel packs associated with the surgical procedure, or one row / multiple rows for a particular surgical procedure with separate instrument trays or peel packs. Columns may be combined or collapsed to a particular surgical procedure to recognize that one set of instruments or peel packs was used for a particular surgical procedure. Tray names used in the medical record system (EMR / EHR) do not necessarily correspond to the tray names available on the count sheet (tray names provided and imported separately).

[0062] In various embodiments, validation may be performed at one or more stages of data ingestion, conversion, or post-conversion. For example, pre-ingestion validation identifies / corrects common errors (such as missing or reordered columns). Validation during conversion finds incorrectly formatted dates or values. Validation after conversion checks for logical errors (such as whether a scheduled end time is before a scheduled start time). Validation errors may be displayed in the user interface at various levels of granularity, such as at the cell, row, or column level of a spreadsheet. Records that may require adjustment may be surfaced before the conversion stage begins.

[0063] Although not shown for the image provider client device, a similar manager (image manager) may be provided and have similar functionality.

[0064] The instrument classification engine 252 is configured to automatically generate a record of the surgical instruments used shown in the image and store the record in a data storage of surgical instrument usage data. As described herein, the received images may be manipulated in various ways. For example, the image metadata may be manipulated by performing a lookup based on the metadata. For example, the engine may look up the OR and facility and pass this information on for downstream processing. The information may be stored in appropriate tables (e.g., rows in an image table and rows in a tray analysis table).

[0065] The optimization engine 262 is configured to automatically analyze records stored in the data storage of surgical tool usage data to identify one or more surgical tool preparation groupings that optimize one or more specified usage metrics.

[0066] The authentication engine 258 is configured to provide validation services for various microservices associated with the system 250. The authentication services may be proprietary or may be provided by a third-party service provider. The authentication services may provide user-based and / or device-based authentication for users to access the portal 256.

[0067] The user portal 256 is configured to interact with users and provide information for display on devices (such as client devices 210 and 220). In various embodiments, the user portal includes an internal portal for internal data collection review and a user-facing portal with a dashboard from which users can obtain information or reports. Examples of dashboards and reports are further described with respect to Figures 3A-8D.

[0068] A particular user may be authenticated by the authentication engine 258 as described further herein. A user may be granted permission to a particular hospital facility, where the user can view reports for that facility or for a system that is a collection of facilities, for example. The optimization reports may be indexed for easy search or other access. The reports that the user has permission to view and the associated metadata are displayed to help the user easily find the information sought. Filtering capabilities may also be provided.

[0069] A taxonomy may be defined to encompass various types of reports so that reports are standardized for comparability across different types of reports. Example reports include, but are not limited to, optimization reports and weekly update reports. Optimization reports may be based on individual trays, procedures, surgeons, etc. For example, tray reports may be per surgeon, per procedure, per medical facility, per medical system, etc. Weekly update reports include the status of client devices (e.g., image provider client device 210 and / or schedule provider client device 220).

[0070] FIG. 3A shows an example of a user interface for instrument selection optimization. In this example, "ORion" refers to the disclosed instrument selection optimization system. Navigation within the dashboard may be aided by a menu (e.g., a menu at the top of the user interface indicating that the current healthcare system is "Acme Health"), and the dashboard is for "Loc1" of the Acme Health system. In this example, one or more facilities and associated captured tray counts are displayed. Selecting element 302 (Is Facility) displays the following user interface:

[0071] FIG. 3B shows an example of a user interface for instrument selection optimization including tray analysis. In this example, each row corresponds to a tray. Relevant tray information (such as the number of images captured, utilization rate, surgeon captured, and whether statistical significance was reached) may be displayed in the corresponding columns as shown. Hovering over a particular tray displays further details in a pop-up window 304. The details include a list of surgeons and the corresponding number of images and utilization rate. Selecting the tray "Major Hand Set" displays the following user interface:

[0072] FIG. 3C shows an example of a user interface for instrument selection optimization, including optimization information for a specific tray. In this example, information for the tray "Major Hand Set" is displayed. Savings in terms of OR & SPD Time and monetary value may be displayed as shown. The number of captured images and surgeons associated with the underlying data may be displayed. Selecting button 312 generates one or more reports, examples of which are shown in FIGS. 5A-8D. The optimization and analysis may be based on the disclosed techniques (e.g., the process in FIG. 1). In this example, optimization results corresponding to Max savings, Everything in OR, and Remove Never Used Instruments are shown. Selecting button 314 displays a list of unused instruments in the next user interface, as shown. Selecting button 316 displays a list of suggestions for achieving maximum savings, as shown in FIG. 3E.

[0073] FIG. 3D shows an example of a user interface for instrument selection optimization, including unused instruments. A list of unused items is shown in this example. This detail allows the user to view specific instruments contained in the current tray (here, the Major Hand Set) that will not be used in any procedure by any surgeon. The user interface also includes a navigation panel 322 that allows the user to perform functions such as getting a PDF report, returning to the tray overview (FIG. 3C), selecting a new tray (FIG. 3B), or selecting a new facility (FIG. 3A).

[0074] FIG. 3E shows an example of a user interface for instrument selection optimization, including optimization for a specific tray. This optimization shows a suggested primary tray containing instruments that are always used, along with a secondary tray containing instruments that are less frequently used. The user can hover over a specific instrument to see more details. In this example, a pop-up window 332 is displayed. The displayed information can be useful for gaining further insight. For example, Dr. Cormorant can be contacted to inquire about why he frequently uses "forcep, Brown-Adson tissue 4 7 / 8."

[0075] 4 illustrates an example user interface for an annotation engine. As described herein, the annotation engine may solicit input from a human annotator. This example user interface provides a user-friendly interface for viewing and / or annotating surgical tools. In this example, 12 options are shown, with the first six options displayed along with an image of the corresponding instrument.

[0076] In various embodiments, the corpus of data includes trays from users and a library with associated labels. The user interface displays the best matches between the instrument labels in the tray and sets in an existing image library and / or allows a human annotator to find the best matches. Matching may be based on cosine similarity and / or a scoring algorithm. For example, for each unique symbol in a particular string, cosine similarity determines how many best matches there are. For example, for "forceps bayonet smooth 7 5 / 8," the best matches may be based on "forceps," "bayonet," and "smooth." An exact match for "7 5 / 8" may not exist; therefore, the first choice 402 is ranked higher than the others. These determined top-level matches may be recommended and displayed for the human annotator to review or select a second match.

[0077] The following figures show example reports containing optimization information determined using the disclosed techniques: The report contents may be presented in a variety of formats in dashboards (such as those described with respect to Figures 3A-3E).

[0078] FIG. 5A shows an example of a report that includes a procedure recipe. This procedure recipe shows how to lay out instruments in a way that is personalized to a particular physician (or more generally, a healthcare professional). Images of the instruments are presented along with their names to help easily identify them. The procedure recipe is customizable for each healthcare professional. For example, a nurse / technician can prepare the instruments according to the procedure recipe. As well as insight into the economics of the procedure, the procedure recipe also provides insight into how frequently a particular instrument is used by a particular physician.

[0079] Figure 5B shows an example of a report that includes a Procedural Playbook. The information in Figure 5B is similar to that shown in Figure 5A unless otherwise noted. Unlike Figure 5A, the information is presented with exact utilization rates without photographs.

[0080] 6 shows an example of a report that includes a tray compliance roadmap. In various embodiments, the roadmap can be used to adhere to tray weight limits and reduce workplace injuries.

[0081] Figure 7 shows an example of a report that includes Procedural Economic Insights. The insights can help establish best practices and generate a surgeon's report card.

[0082] 8A-8D show an example of a report that includes service line optimization. In this example, the optimization is based on generalization across different physicians. For example, system-wide cost containment and standardization may be improved.

[0083] FIG. 9 is a functional diagram illustrating a computer system programmed for instrument selection optimization, according to some embodiments. Clearly, other computer system architectures and configurations can be used to implement the described instrument selection optimization techniques. Computer system 900, including various subsystems as described below, includes at least one microprocessor subsystem (also referred to as a processor or central processing unit (CPU) 902). For example, processor 902 can be implemented by a single-chip processor or multiprocessor. In some embodiments, processor 902 is a general-purpose digital processor that controls the operation of computer system 900. In some embodiments, processor 902 further includes one or more coprocessors or special-purpose processors (e.g., graphics processor, network processor, etc.). Using instructions retrieved from memory 910, processor 902 controls the receipt and manipulation of input data received at input devices (e.g., image processing device 906, I / O device interface 904) and the output and display of data at output devices (e.g., display 918).

[0084] The processor 902 is bidirectionally coupled to memory 910, which may include, for example, one or more random access memories (RAMs) and / or one or more read-only memories (ROMs). As is known to those skilled in the art, the memory 910 may be used as general storage, temporary (e.g., scratchpad) memory, and / or cache memory. The memory 910 may further be utilized to store input data and processed data, as well as programming instructions and data in the form of data objects and text objects, in addition to other data and instructions for processes executed on the processor 902. As is also known to those skilled in the art, the memory 910 typically comprises basic operating instructions, program code, data, and objects used by the processor 902 to execute functions (e.g., programmed instructions). For example, the memory 910 may include any suitable computer-readable storage medium, as described below, depending, for example, on whether data access needs to be bidirectional or unidirectional. For example, the processor 902 may directly and very quickly store and retrieve frequently needed data from a cache memory included in the memory 910.

[0085] A removable mass storage device 912 provides additional data storage capacity for computer system 900 and is optionally connected bidirectionally (read / write) or unidirectionally (read only) to processor 902. Fixed mass storage 920 may also provide additional data storage capacity, for example. For example, storage devices 912 and / or 920 may include computer-readable media such as magnetic tape, flash memory, PC cards, portable mass storage devices such as hard drives (e.g., magnetic, optical, or solid-state drives), holographic storage devices, and other storage devices. Mass storage 912 and / or 920 typically stores additional programming instructions, data, etc. that are not typically utilized by processor 902. It will be understood that the information retained in mass storage 912 and 920 may, if desired, be incorporated in standard fashion into part of memory 910 (e.g., RAM) as virtual memory.

[0086] In addition to providing processor 902 with access to the storage subsystem, bus 114 may also be used to provide access to other subsystems and devices. As shown, these may include a display 918, a network interface 916, an input / output (I / O) device interface 904, an image processing device 906, and other subsystems and devices. For example, image processing device 906 may include a camera, a scanner, etc. I / O device interface 904 may include a device interface for interacting with a touchscreen (e.g., a capacitive touch-sensitive screen that supports gesture interpretation), a microphone, a sound card, a speaker, a keyboard, a pointing device (e.g., a mouse, a stylus, a human finger), a global positioning system (GPS) receiver, an accelerometer, and / or any other suitable device interface for interacting with system 900. Multiple I / O device interfaces may be used with computer system 900. The I / O device interfaces may include generic and customized interfaces that enable the processor 902 to send data and, more typically, receive data from other devices (such as keyboards, pointing devices, microphones, touch screens, transducer card readers, tape readers, voice or handwriting recognition devices, biometric readers, cameras, portable mass storage devices, and other computers).

[0087] The network interface 916 allows the processor 902 to be connected to another computer, computer network, or telecommunications network using a network connection, as shown. For example, through the network interface 916, the processor 902 can receive information (e.g., data objects or program instructions) from another network or output information to another network in the course of performing method / processing steps. Information, often represented as a series of instructions executed on the processor, can be received from and output to another network. An interface card (or similar device) and appropriate software implemented (e.g., executed / performed) by the processor 902 can be used to connect the computer system 900 to an external network and transfer data according to standard protocols. For example, various process embodiments disclosed herein may be executed on the processor 902 or may be executed over a network (such as the Internet, an intranetwork, or a local area network) with a remote processor that shares some of the processing. Additional mass storage devices (not shown) may be connected to the processor 902 through the network interface 916.

[0088] Additionally, various embodiments disclosed herein further relate to computer storage products including a computer-readable medium having program code thereon for performing various computer-implemented operations. A computer-readable medium includes any data storage device that can store data, which can thereafter be read by a computer system. Examples of computer-readable media include, but are not limited to: magnetic media such as disks and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as optical disks; and specially configured hardware devices such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and ROM / RAM devices. Examples of program code include, for example, machine code produced by a compiler, or files containing high-level code (e.g., scripts) that can be executed using an interpreter.

[0089] The computer system shown in FIG. 9 is just one example of a computer system suitable for use with various embodiments disclosed herein. Other computer systems suitable for such use may include more or fewer subsystems. In some computer systems, the subsystems may share components (e.g., for devices with touchscreens, such as smartphones, tablets, etc., the I / O device interface 904 and display 918 share a touch-sensitive screen component that both detects user input and displays output to the user). Furthermore, the bus 114 is an example of any interconnection scheme that functions to link the subsystems. Other computer architectures having different configurations of subsystems may be used.

[0090] Although the above-described embodiments have been described in some detail for ease of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and are not intended to be limiting.

Claims

1. 1. A method comprising: receiving an inventory of surgical tools available for use during the surgical procedure; receiving an image showing at least a portion of the available surgical tools used during the surgical procedure; generating, at least in part automatically, a record of the used surgical tools shown in the image; storing said record in a data storage of surgical tool usage data; automatically analyzing records stored in said data storage of surgical tool usage data to identify one or more surgical tool readiness groupings that optimize one or more specified usage metrics; A method comprising:

2. 10. The method of claim 1, wherein the description of the surgical tools available for use during the surgical procedure is received from a first source, and the images showing the at least some of the available surgical tools used during the surgical procedure are received from a second source different from the first source.

3. 10. The method of claim 1, wherein the inventory of the surgical tools available for use during the surgical procedure includes an instrument count sheet.

4. 10. The method of claim 1, wherein automatically generating the record of the used surgical instruments shown in the images includes annotating each of at least a portion of the used surgical instruments based at least on a plurality of previously received images.

5. 5. The method of claim 4, wherein the total number of previously received images utilized for the annotation is based at least on a robustness analysis of the previously received images performed using a threshold indicating a reliability of the previously received images.

6. 5. The method of claim 4, wherein the total number of previously received images utilized for the annotation is based at least on a coverage analysis of the previously received images performed using a threshold indicative of a level of representativeness of the surgical procedure with respect to a group of surgical procedures.

7. 2. The method of claim 1, wherein automatically generating the record of the used surgical tools shown in the image includes identifying each of at least some of the used surgical tools based at least on a trained machine learning model.

8. 2. The method of claim 1, wherein automatically generating the record of the used surgical instruments shown in the image includes identifying each of at least some of the used surgical instruments without using the description of the surgical instruments available for use during the surgical procedure.

9. 10. The method of claim 1, wherein the record of the used surgical tools shown in the image is based at least on the description of the surgical tools available for use during the surgical procedure.

10. 10. The method of claim 1, wherein the one or more surgical tool preparation groupings are organized into one or more trays.

11. 11. The method of claim 10, wherein the one or more trays include a main tray containing a first subset of the used surgical instruments and an auxiliary tray containing a second subset of the used surgical instruments.

12. 2. The method of claim 1, wherein automatically analyzing the records stored in the data storage of the surgical tool usage data to identify the one or more surgical tool readiness groupings that optimize the one or more specified usage metrics includes performing a service line analysis.

13. 2. The method of claim 1, wherein automatically analyzing the records stored in the data storage of the surgical tool usage data to identify the one or more surgical tool readiness groupings that optimize the one or more specified usage metrics includes determining a co-use pattern of a first one of the used surgical tools being used with a second one of the used surgical tools at a frequency that meets a usage threshold.

14. 10. The method of claim 1, further comprising outputting a report based at least on the automated analysis of the records stored in the data storage of the surgical tool usage data to identify the one or more surgical tool readiness groupings that optimize the one or more specified usage metrics.

15. 10. The method of claim 1, wherein the one or more designated usage metrics include at least one of a usage rate corresponding to each appliance.

16. 2. The method of claim 1, wherein automatically analyzing the records stored in the data storage of the surgical tool usage data to identify the one or more surgical tool preparation groupings that optimize the one or more specified usage metrics comprises performing a robustness analysis to determine reliability of the identified one or more surgical tool preparation groupings.

17. 2. The method of claim 1, wherein automatically analyzing the records stored in the data storage of the surgical tool usage data to identify the one or more surgical tool preparation groupings that optimize the one or more specified usage metrics comprises performing a coverage analysis to determine a level of representativeness of features associated with the surgical procedure.

18. 18. The method of claim 17, wherein automatically analyzing the records stored in the data storage of the surgical tool usage data to identify the one or more surgical tool readiness groupings that optimize the one or more specified usage metrics comprises performing a coverage analysis to determine a level of representativeness of features associated with the surgical procedure based at least on the description of the surgical tools available for use during the surgical procedure.

19. 1. A system comprising:

1. A processor, comprising: receiving an inventory of surgical tools available for use during the surgical procedure; receiving an image showing at least a portion of the available surgical tools used during the surgical procedure; generating, at least in part automatically, a record of the used surgical tools shown in the image; storing said record in a data storage of surgical tool usage data; a processor configured to automatically analyze the records stored in the data storage of surgical tool usage data to identify one or more surgical tool preparation groupings that optimize one or more specified usage metrics; a memory coupled to the processor and configured to provide instructions to the processor; A system comprising:

20. A computer program product embodied in a non-transitory computer-readable medium, computer instructions for receiving an inventory of surgical tools available for use during a surgical procedure; computer instructions for receiving an image depicting at least a portion of the available surgical tools used during the surgical procedure; computer instructions for at least partially automatically generating a record of the used surgical implements shown in the image; computer instructions for storing said record in a data storage of surgical tool usage data; computer instructions for automatically analyzing records stored in said data storage of surgical tool usage data to identify one or more surgical tool readiness groupings that optimize one or more specified usage metrics; A computer program product comprising:

Images