Multi-User Surgical Cart

Abstract

The system includes a surgical cart including a local client access point, a monitor, a cart computer, a first external interface coupled to the local client access point, and a second external interface coupled to the primary monitor. The surgical cart can host a web server to which one or more client devices can connect using a web browser. The web server can provide access to one or more surgical applications hosted by the surgical cart during surgery.

Description

[Technical Field]

[0001] (Reference to Related Application) This application claims priority to U.S. Provisional Patent Application No. 63 / 164,442, filed March 22, 2021, the entirety of which is incorporated herein by reference for all purposes. [Background technology]

[0002] In surgical procedures such as spinal fusion, surgeons and other healthcare professionals make trade-offs between invasiveness, efficiency, and radiation exposure to achieve surgical goals. Various technologies have been introduced into the operating room to help navigate these and other trade-offs, often resulting in the proliferation of standalone technologies, which can create challenges in a constrained operating room footprint. Summary of the Invention

[0003] In one example, there is a method performed during or in preparation for surgery in an operating room. The method includes, using a computer on a surgical cart located in the operating room, determining a network name, determining a password, determining a uniform resource locator, determining a code, providing a network configuration user interface showing the network name, password, uniform resource locator, and code, and hosting a first web page at an Internet Protocol address. The method further includes, using an access point on the surgical cart, providing a wireless network having a network name and protected using a password. The method further includes, during surgery, using a first client device located in the operating room to connect to the wireless network using the network name and password, launching a web browser, and navigating the web browser to the uniform resource locator. The method further includes detecting, with a computer on a surgical cart located within the operating room, navigating a web browser to a uniform resource locator, resolving the uniform resource locator to an Internet Protocol address where a first web page is hosted, and providing the first web page to a first client device, the first web page including a user interface element. The method further includes rendering, with the first client device located within the operating room, the provided first web page in a web browser, receiving user input representing code through the user interface element of the first web page in the web browser, and providing the user input to the computer on the surgical cart.The method further includes receiving, using a computer on the surgical cart, user input representing a code from a first client device, determining a match between the code and the user input representing the code, and during the surgery, using the computer on the surgical cart, after determining a match between the code and the user input representing the code, providing a first surgical application to the first user via a web browser on the first client device based on the interaction from the client device, and providing a second surgical application to the second user via a monitor on the surgical cart.

[0004] Alternatively or additionally to any of the embodiments in this section, the method further includes using a computer on a surgical cart located in the operating room to connect the computer on the surgical cart to the Internet during or in preparation for the surgery, and sharing the connection to the Internet from the surgical cart to a first client device, using the first client device located in the operating room to access the Internet from the first client device through the shared connection.

[0005] Alternatively or additionally to any of the embodiments in this section, accessing the Internet from the first client device through a shared connection includes accessing a remote neuromonitoring service via the Internet.

[0006] Alternatively or additionally to any of the embodiments in this section, the method further includes simultaneously hosting the first surgical application and the second surgical application using hosting software on the computer.

[0007] Alternatively or additionally to any of the embodiments in this section, the method further includes determining, using a computer on a surgical cart located in the operating room, a role of a first user of a first client device during or in preparation for surgery, and providing the first surgical application to the first user based on the role, and determining the role of the first user of the first client device includes providing, using a computer on a surgical cart located in the operating room, during or in preparation for surgery, a second page on a web browser, the second page including one or more selectable user interface elements representing different user types, and determining user interface activation of at least one of the one or more selectable user interface elements corresponding to the role.

[0008] Alternatively or additionally to any of the embodiments in this section, the role is selected from the group consisting of a neurosurgeon, a company representative, and an imaging technician.

[0009] Alternatively or in addition to any of the embodiments in this section, the first surgical application and the second surgical application are different surgical applications selected from the group consisting of a neuromonitoring application, a planning application, a navigation application, an imaging application, and a rod bending application.

[0010] Alternatively or in addition to any of the embodiments in this section, providing the second surgical application to the second user via the surgical cart monitor includes accessing the second surgical application using a web browser running on the surgical cart computer.

[0011] In one example, a system includes a surgical cart, the surgical cart including a local client, a primary monitor, and a cart computer. The cart computer includes one or more processors, a memory, and a plurality of external interfaces. The plurality of external interfaces includes a first external interface coupled to a local client access point and a second external interface coupled to the primary monitor. The memory includes instructions that, when executed by the one or more processors, cause the one or more processors to determine a network name, determine a password, determine a uniform resource locator, determine a code, provide a network configuration user interface showing the network name, password, uniform resource locator, and code, host a first web page at an Internet Protocol address, detect a web browser of a first client device navigating to the uniform resource locator, resolve the uniform resource locator to an Internet Protocol address where the first web page is hosted, and transmit the first web page including the user interface elements to the first client device. and receiving user input representing a code from a client device, determining a match between the code and the user input representing the code, and, after determining a match between the code and the user input representing the code, based on the interaction from the client device, providing a first surgical application to a first user via a web browser on the first client device and providing a second surgical application to a second user via a primary monitor of a surgical cart; the local client access point includes instructions that, when executed by one or more processors of the local client access point, cause the local client access point to provide a wireless network having a network name and protected using a password.

[0012] Alternatively or additionally to any of the embodiments in this section, the memory further includes instructions that, when executed, cause the one or more processors to share an Internet connection from the cart computer to the client device.

[0013] Alternatively or in addition to any of the embodiments in this section, the memory further includes instructions that, when executed, cause the one or more processors to determine a role of a first user of the client device, and providing the first surgical application to the first user is based on the role.

[0014] Alternatively or additionally to any of the embodiments in this section, determining a role of a first user of a client device includes providing the web browser with a second page including one or more selectable user interface elements representing different user types, and determining activation of at least one user interface element of the one or more selectable user interface elements corresponding to the role.

[0015] Alternatively or additionally to any of the embodiments in this section, the role is selected from the group consisting of a neurosurgeon, a company representative, and an imaging technician.

[0016] Alternatively or in addition to any of the embodiments in this section, the first surgical application and the second surgical application are different surgical applications selected from the group consisting of a neuromonitoring application, a planning application, a navigation application, an imaging application, and a rod bending application.

[0017] Alternatively or in addition to any of the embodiments in this section, the system further includes a first client device, a second client device connected to the local client access point, and a third client device connected to the local client access point.

[0018] Alternatively or additionally to any of the embodiments in this section, the system further includes an imaging device and a camera.

[0019] Alternatively or additionally to any of the embodiments in this section, the cart computer is located within a cart computer housing and the local client access point is located within a client access point housing separate from the cart computer housing.

[0020] Alternatively or additionally to any of the embodiments in this section, the local client access point is coupled to the cart computer via an Ethernet cable. [Brief explanation of the drawings]

[0021] [Figure 1] 1 illustrates an exemplary system having one or more components in an operating room.

[0022] [Figure 2] 1 shows the System Cart software.

[0023] [Figure 3] Indicates the core software.

[0024] [Figure 4] Illustrates a typical clinical workflow in which the core software is used.

[0025] [Figure 5]1 illustrates an exemplary startup user interface.

[0026] [Figure 6] 1 shows a camera setup user interface.

[0027] [Figure 7] 1 illustrates an exemplary method for connecting one or more local client devices to a cart.

[0028] [Figure 8] 1 illustrates an exemplary wired network configuration user interface including a network configuration interface.

[0029] [Figure 9] 1 illustrates an exemplary user interface including a network settings interface.

[0030] [Figure 10] 1 illustrates an exemplary intraoperative page. DETAILED DESCRIPTION OF THE INVENTION

[0031] An example of the disclosure includes a cart (e.g., referred to as a “technical cart,” “surgical cart,” or “system cart”) for use in an operating room that provides multiple different surgical applications (e.g., navigation, neuromonitoring, surgical planning, imaging, rod bending, and robotic control) from the cart. Generally, the cart is a portable unit configured to be easily movable within or between operating rooms that can be used during surgery to interact with one or more of the multiple surgical applications (e.g., by providing the cart with lockable wheels). As an example, the cart may include a computer, output devices (e.g., a monitor and speakers), input devices (e.g., a monitor touchscreen and keyboard), and connections for other devices (e.g., a network connection, an imaging device connection, and a navigation camera connection). Integrating multiple different applications into a cart can conserve space in the operating room (e.g., by reducing the need for multiple different standalone devices). However, integrating multiple applications into a single cart can lead to crowding around the devices as users compete for access to the cart's input / output devices. One way to address crowding and other challenges is to provide functionality to multiple different client devices (e.g., tablet computers) to interact with the functionality provided by the cart from different locations within the operating room. The cart includes networking and server hosting technology to enable multiple client devices to interact with the technology cart in an efficient manner. Additional benefits that implementation may involve include providing real-time instrument navigation and trajectory information to surgeons during spine surgery, tracking the position of surgical instruments in three-dimensional space, locating anatomical structures for either open or minimally invasive spine surgical procedures, minimizing the possibility of pedicle disruption, and increasing surgeon efficiency through expanded software configuration offerings. An example of a system in which the cart can operate is shown in Figure 1.

[0032] (Example System) FIG. 1 illustrates an exemplary system 100 having one or more components within an operating room 10. The operating room 10 is a room within a hospital, clinic, or other healthcare facility configured for use in surgery and where surgery is routinely performed. The system 100 includes a system cart 110, a camera 180, an imaging device 182, and one or more client devices (e.g., clients) 190. The components of the system 100 can be located within and used from the operating room 10. The components of the system 100 can be coupled to a network 20. The operating room 10 can include other components for use during surgery, such as a bed, an instrument tray, lighting, other technical carts, and other devices and tools. The network 20 can be a set of two or more communicatively coupled computers, such as a local area network, a hospital area network, the Internet, or a combination thereof, among others.

[0033] The surgical cart 110 is a mobile station that includes one or more components that provide functionality for use during a surgical procedure. For example, as shown, the surgical cart 110 includes, among other components, a cart computer 120, a local client access point 130, speakers 150, a primary monitor 160, and a secondary monitor 170.

[0034] The cart computer 120 is the computing environment of the cart 110 in which the technology described herein can be implemented. The cart computer 120 is a set of one or more virtual or physical computers configured to generate output based on data (e.g., input). In many examples, the cart computer 120 is a workstation or desktop computer, but can take other forms. As shown, the cart computer 120 includes one or more cart processors 122, a cart memory 124, and one or more external interfaces 140.

[0035] The one or more cart processors 122 are one or more physical or virtual components configured to retrieve and execute instructions (e.g., from cart memory 123). In many examples, the one or more cart processors 122 are central processing units, but can take other forms, such as a microcontroller, a microprocessor, a graphics processing unit, a tensor processing unit, other processors, or combinations thereof. In one example, the one or more cart processors 122 include both a central processing unit (e.g., one offered by INTEL or AMD) and a workstation-grade graphics card (e.g., one offered by NVIDIA or AMD).

[0036] Cart memory 124 is one or more physical or virtual components configured to store information such as data or instructions. In some examples, cart memory 124 includes a main memory (e.g., random access memory) or long-term memory (e.g., solid-state drive) of a computing environment. Memory can be a temporary or non-temporary computer-readable or processor-readable storage medium.

[0037] External interface 140 is a set of one or more components to which cart computer 120 can provide output or receive input (e.g., from components external to cart computer 120). For example, external interface 140 can include one or more user input components, such as one or more sensors, buttons, pointers, keyboards, mice, gesture controls, touch controls (e.g., touch strips or touch screens), eye trackers, voice recognition controls (e.g., microphones coupled to appropriate natural language processing components), other user input components, or combinations thereof. External interface 140 can also include one or more user output components, such as one or more lights, displays, speakers, haptic feedback components, other user output components, or combinations thereof. The interface 1030 can include one or more components configured to provide output to and receive input from other devices, such as one or more ports (e.g., a Universal Serial Bus (USB) port, a Thunderbolt® port, a serial port, a parallel port, an Ethernet port) or wireless communication components (e.g., a component configured to communicate according to one or more radio frequency protocols, such as Wi-Fi, Bluetooth®, ZIGBEE®, or other protocols). In some examples, the interface 1030 includes a video input port for obtaining video or image input from a device such as an intraoperative radiography imaging device (e.g., a C-arm) or an exoscope.

[0038] In one example, external interface 140 includes a touch display interface, a local client interface, a camera interface, an imaging interface, a video input, a video output, a USB interface, and a remote monitoring interface. The USB interface can provide USB file system access capabilities for exporting log files, screenshots, reports, and diagnoses, and for importing DICOM (Digital Imaging and Communications in Medicine) data or other data.

[0039] In one embodiment, the touch display interface is in the form of a USB port coupled to a touch display (e.g., primary monitor 160 or secondary monitor 170). One or more touch displays coupled to the interface can be calibrated for touch using a utility (e.g., "MultiDigimon.exe-touch" provided with WINDOWS) to select which monitors are included for touch-based input.

[0040] The local client interface of the external interface 140 can include one or more wired and wireless interfaces. In one example, the local client interface can include a local client access point 130 (e.g., in the form of a wireless router with an uplink connection to the cart's local wireless control network interface). The wired interface can include a dedicated RJ45 network port for connecting locally wired clients. In one example, the wired connection with the client is made first through a wired connection between the cart computer 120 and the local client access point 130, and then between the local client access point 130 and the client device 190.

[0041] In one example, the camera interface of external interface 140 is an RJ45 network interface. In some examples, the camera interface provides power to the camera using a power over Ethernet protocol.

[0042] In one example, the imaging interface of external interface 140 can be a network connection for an imaging system such as those provided by SIEMENS or ZIEHM, among others. The imaging interface can be in the form of an RJ45 network interface with a static IP address. In some examples, imaging device 182 is connected to cart computer 120 via sneakernet.

[0043] The video input of the external interface 140 may include, for example, a DVI-in port or an HDMI-in port connected to a capture card.

[0044] The video output of the external interface 140 may include, for example, a video output for an external monitor. The video output may include, for example, a USB to HDMI adapter for mirroring one of the cart's displays to an external HDMI connection. Another example is a USB to DVI adapter for mirroring one of the displays to an external DVI connection.

[0045] In one embodiment, the USB port of the external interface 140 can be configured for use in connecting a removable drive device for use during operation of the cart, such as exporting reports, logs, or screenshots.

[0046] The remote monitoring interface of the external interface 140 can include internet connectivity of the cart used to connect the cart 110 to a remote monitoring service for publishing neuromonitoring data for remote oversight.

[0047] The local client access point 130 is a network device configured to communicate with one or more devices over one or more wired or wireless connections. In one example, the local client access point is a special-purpose computer configured to manage networking traffic (e.g., receive and transmit data packets according to a networking protocol) between two or more devices coupled to the networking device. The local client access point 130 can be located in a dedicated housing separate from the housing of the cart computer 120. In another example, the local client access point 130 can be located in a Peripheral Component Interconnect Express (PCIe) card coupled to the cart computer 120. In one example, the local client access point 130 is configured as a special-purpose computing device by running a networking / firewall operating system or firmware, such as the open source projects PFSENSE, TOMATO, DD-WRT, or proprietary software. The local client access point 130 can further include special-purpose hardware, such as special-purpose switching hardware.

[0048] The local client access point 130 may include one or more antennas and one or more radios configured to provide the wireless client network 132. The antennas, radios, and other components may be configured to provide the wireless client network according to one or more standards, such as IEEE 802.11, BLUETOOTH, ZIGBEE, or other protocols. The local client access point 130 may be configured with software to provide the wireless client network 132 using the one or more antennas or radios so that one or more client devices 190 can connect to the wireless client network 132.

[0049] In some examples, the cart computer 120 communicates directly with one or more client devices 190 through an ad-hoc connection, which may be encrypted or otherwise secured.

[0050] In one example, The cart 110 includes one or more speakers 150. Software running on the cart 110 can provide the ability to generate sound (audio) events based on events detected by the software. The created sounds can be generated by playing audio files (e.g., waveform audio file format files) using one or more speakers 150. The tones that can be played and their associated audio files can be defined within each application that provides the ability to play sounds.

[0051] Imaging device 182 is a patient imaging device, such as a computerized tomography (CT) scanner or a magnetic resonance imaging (MRI) scanner. In one example, imaging device 182 is in the form of a C-arm. In one example, imaging device 182 communicates directly with cart 110 (e.g., via a wired or wireless connection) or indirectly with cart 110.

[0052] The client device 190 can be one or more computing devices. Within the context of the system 100, the client device 190 can be a device used by one or more users during operation of the cart 110 to access services. Advantageously, the client device 190 can enable multiple users to simultaneously access services provided by the cart 1100 without having to crowd around the cart. Additionally, the client device 190 can be a portable computing device, such as a tablet, laptop, phone, wearable device, virtual reality device, or augmented reality device, among others, to enable portable use of the device at a convenient location within the operating room 10. In some examples, the client device 190 is a consumer-grade device or a specialized medical-grade device. The client device 190 can include, among other things, one or more processors, memory, and an interface device (e.g., a touchscreen). The illustrated client device 190 includes a browser 192. Browser 192 is software that, when executed by one or more processors of client device 190, causes client device 190 to retrieve and render pages, such as web pages (whether or not the web pages themselves are actually retrieved from the World Wide Web). Exemplary browsers include CHROMIUM, CRHOME, FIREFOX, SAFARI, INTERNET EXPLORER, EDGE, and OPERA, among others. In exemplary implementations, client devices 190 are local client devices in that they are configured for use in close proximity to cart 110 and throughout use within operating room 10, for example, by providing features related to activities occurring within operating room 10. In some examples, client device 190 operates as a remote terminal that controls the execution of surgical applications on cart 110, rather than primarily performing surgical functions on client device 190.

[0053] In some examples, a hardware or software firewall is placed between the camera and the cart computer 120.

[0054] 2 illustrates system cart software 200. System cart software 200 includes computer-executable instructions and associated components and resources (including, for example, data) for causing one or more processors to perform one or more system cart operations. System cart software 200 includes hosting software 202, a browser 204, surgical platform software 210, operating system software 280, and drivers 290. Surgical platform software 210 includes core software 220, neuromonitoring software 230, planning software 240, navigation software 250, imaging software 260, and bending software 270.

[0055] The hosting software 202 is software that, when executed, causes the cart 110 to provide a web server to which one or more client devices 190 can connect. In one example, the hosting software is implemented using WINDOWS WEB SERVER (e.g., INTERNET INFORMATION SERVICES by MICROSOFT). Although the server may be a web server, one or more pages or other aspects hosted by the hosting software 202 need not be accessible on the World Wide Web or to devices outside of the operating room 10.

[0056] Browser 204 is software that provides a web browser and may include one or more aspects as described above with respect to browser 192. In one example, browser 204 is an embedded browser or a headless browser.

[0057] The core software 220 includes session management, workflow navigation, network connectivity, image acquisition, camera interface and tracking data, external monitor support, file export (reports, screenshots, logs, images, diagnostics), events and annotations, timers, and system maintenance functions. The core software 220 is described in more detail in connection with FIG. 3.

[0058] The neural monitoring software 230 includes computer-executable instructions, associated components, and resources (e.g., data) to cause one or more processors to perform one or more neural monitoring operations. For example, the neural monitoring software 230 provides intraoperative neurophysiological monitoring during spinal surgery. The neural monitoring software 230 enables the cart 110 to provide information directly to the surgeon to assist in assessing the patient's neurophysiological status. The neural monitoring software 230 can obtain information by triggering electrical stimulation of via electrodes placed on surgical accessories and monitoring the electromyography (EMG), motor evoked potential (MEP), or somatosensory evoked potential (SSEP) response of the nerve. Additionally or alternatively, the neural monitoring software provides features that enable the surgeon to characterize and evaluate nerves for use in nerve avoidance. For example, the software 230 can provide features for providing proximity information before, during, or after bone preparation and bone screw placement. In one example, the neural monitoring software 230 provides integrated neural monitoring. Exemplary neuromonitoring configurations are described, for example, in U.S. Patent Nos. 8,538,539, 8,548,579, 8,550,994, 8,556,808, 8,562,521, 8,591,432, 8,602,982, 8,628,469, 8,634,904, 8,663,100, 8,672,840, 8,679,006, 8,696,559, 8,708,899, 8,738,1 23, 8,747,307, 8,753,271, 8,764,649, 8,768,450, 8,784,330, 8,821,396, 8,942,801, 8,945,004, 8,956,283, 8,977,352, 8,989,866, and 9,037,250, which are incorporated herein by reference in their entireties for all purposes.

[0059] The planning software 240 includes computer-executable instructions and associated components and resources (including, for example, data) to cause one or more processors to perform one or more planning operations. An exemplary planning software 240 includes the IGA platform by NUVASIVE, INC. Exemplary planning configurations are described, for example, in U.S. Patent Application Publication Nos. 2021 / 0030443, 2020 / 0170712, and 2015 / 0100091, which are incorporated by reference herein in their entireties for all purposes.

[0060] The navigation software 250 includes computer-executable instructions and associated components and resources (e.g., data) to cause one or more processors to perform one or more navigation operations. An exemplary navigation configuration is described in U.S. Patent Application Publication No. 2018 / 0092699, which is incorporated by reference in its entirety for all purposes.

[0061] The imaging software 260 includes computer-executable instructions and associated components and resources (e.g., data) to cause one or more processors to perform one or more imaging operations. Exemplary imaging software 260 includes instructions for acquiring and processing images. Exemplary imaging software 260 includes LESSRAY by NUVASIVE, INC. Exemplary imaging software is described in U.S. Patent Nos. 8,526,700, 9,510,771, 8,718,346, 8,792,704, 8,908,952, U.S. Patent Application Publication No. 2017 / 0165008, 9,785,246, 10,444,855, and 10,139,920, which are incorporated by reference in their entireties for all purposes.

[0062] The bending software 270 includes computer-executable instructions and associated components and resources (e.g., data) to cause one or more processors to perform one or more bending operations. For example, the bending operations may include planning and providing instructions for bending rods for use in spinal procedures. An exemplary bending software 270 includes BENDINI by NUVASIVE, INC. Exemplary bending software configurations are described in U.S. Patent Application Publication No. 2014 / 0137618, U.S. Patent No. 9,848,922, U.S. Patent No. 7,957,831, and U.S. Patent No. 8,549,888, which are incorporated by reference in their entireties for all purposes.

[0063] The operating system software 280 includes computer-executable instructions and associated components and resources (e.g., data) for causing one or more processors to perform one or more operations related to an operating system. The operating system can provide configuration, such as control over the allocation of resources (e.g., processing resources, memory resources, and networking resources) and devices (e.g., input devices, output devices, or networking devices) among programs running on the computer. In one example, the operating system software implements an embedded operating system (e.g., Windows IoT by Microsoft Corp.) or other types of operating systems (e.g., Windows 11 or Windows 10 Enterprise LTSC by Microsoft Corp.).

[0064] Drivers 290 include computer-executable instructions and associated components and resources (including, for example, data) to cause one or more processors to perform one or more operations related to the hardware.

[0065] The system cart 110 may include other software for use during a medical procedure. In one example, the cart 110 includes software for creating or defining a custom implant (e.g., a custom intracorporeal implant) for a patient.

[0066] The various software may provide application programming interfaces or other interfaces for communicating between each other. Two or more of the software components may work together to perform a function. The software may be configured to perform one or more of the methods or operations described herein.

[0067] Various software may provide user interfaces for providing data to and receiving information from one or more users. A variety of user interface elements may be used, such as menus, banners, breadcrumbs, buttons, button bars, checkboxes, button lists, toggle buttons, up / down buttons, confirmation dialogs, data pills, date elements, dropdown menus, numeric elements, orientation editors, progress bars, scrollable elements, scrollable grids, sliders, spinners, toolbars, tooltips, and wizard steps.

[0068] (Core Software) 3 illustrates core software 220. Here, "core" means central, and does not imply that one or more aspects of the core software are essential to the inventions described herein.

[0069] As shown, the exemplary core software 220 includes an engine 304, which may be referred to as subunits, submodules, subcomponents, or engines. The decomposition into engines 304 provides software modularization and defines the scope of functionality dependent on the subunits. The core software 220 may be implemented in other ways. In the exemplary implementation, each subunit fulfills its function only when incorporated into the core software 220 and, therefore, need not be considered a software unit that can be described or tested in isolation. A module may be a group of functions and data structures and interfaces that allow other modules or components to interact with the module. The engine 304 may be a software component that contains base capabilities from which other applications can be built, implementing interfaces to software and hardware components used and shared within each supported application.

[0070] The core software 220 can use a message bus 302 with a publish / subscribe design pattern for inter- and intra-module communication. The message bus can allow for decoupling of modules as well as decoupling of individual services within a single module. An exemplary implementation supports intra-process communication and uses MICROSOFT.NET events to send messages to subscribers. Bus topics can be configured for each module's configuration file, where threading and the publish / subscribe pattern are specified for each topic the module is aware of. In some implementations, the core software 220 can be configured so that there are no compile-time dependencies between different modules, and all interactions between modules are via the message bus 302 with the publish / subscribe pattern. Bus topics and arguments can be resolved at compile time to ensure type safety during runtime. Framework components can be used to define shared topic and argument data types.

[0071] As shown, the engines 304 include a session management engine 306, a multi-application system engine (e.g., a multi-application system component) 308, a monitor support engine 310, a local client profile (e.g., a local client profile engine) 312, a general-purpose workflow engine 322, an audible information engine 324, a timer engine 326, a screen capture engine 328, a device engine 330, a local client support engine 332, an imaging control device engine 334, and a camera tracking engine 336.

[0072] The session management engine 306 can provide the ability to start and stop sessions within the system 100. A session can correspond to a period of time for which the cart 110 is to be used. For example, a session can correspond to a surgery for which the cart 110 provides functionality (e.g., including pre- and post-operative setup and wrap-up). The current state of a session can be propagated to each connected client device 190 for synchronization. For example, as a session transitions between an initiation phase, a setup phase, a pre-operative phase, an intraoperative phase, and an end procedure phase, the current phase can be propagated to each client device 190. In an exemplary implementation, creating a session includes creating a database (e.g., an SQL database) to store session-specific data and a folder or other location to store diagnostic information and screenshots. The session management engine 306 can start or restore a session via a request from a user interface element in the session user interface.

[0073] The session management engine 306 can provide functionality for starting a new session, restoring a previous session, and terminating a session. Starting a new session can set state to default initial values ​​for all applications. The session management engine 306 can orchestrate session initiation state with each application. Each application can be responsible for performing session startup and can notify the core application 220 when the application is ready. Restoring a session can restore all required values. The session management engine 306 can be responsible for notifying each application that a session is being restored with information, identifying which sessions are being restored and notifying all applications when the session restoration is complete. Each application can be configured to be responsible for performing restoration per application-specific session restoration requirements. Terminating a session prepares the cart 110 for the next new session, such as by notifying the application that the current session has stopped. In response, each application resets its own state as defined in each application-specific software requirements specification. A new database can be prepared when the next session is initiated. The session management engine 306 can further organize communication of session state using an event bus that includes the before and after stages of state changes. Components can include base class implementations from which modules are derived to encapsulate and simplify session lifecycle management and services without having to individually subscribe and publish to each session lifecycle bus topic.

[0074] The multi-application system component 308 includes software-hardware interfaces for various components, such as an external monitor component, an imaging component, monitoring accessories, a tracking camera, a local client router, a hospital network connection, a remote monitoring portal, a USB interface, and software interfaces, among others. The core multi-application system component 308 can cause the display of device status information related to patient management devices. For example, the component 308 can detect and manage connection status and publish connection status information and any available version information to the messaging bus 302. The core software 220 can listen on the messaging bus 302 for messages related to resource status and propagate the status and any provided version information to the user interface.

[0075] In some examples, the core software 220 can provide remote monitoring functionality. Connection to a remote monitoring portal can be provided as part of the core software 220 and a network connection that provides access to the Internet and connects to the remote monitoring portal. The ability of carts 110 to connect to the remote monitoring portal can be managed through the remote monitoring portal, for example, by registering each cart's serial number. A menu item can be provided to initiate remote monitoring and can be made available when an Internet connection is detected. Once connected to the remote monitoring portal, this menu item can become Chat and invoke a remote monitoring chat dialog.

[0076] The multi-application system engine 308 can interact with stored configuration data. The stored configuration data can include system-level configuration values, such as anatomical structure, approach, spinal level, workflow definition, session restore options, data retention, and file system configuration. The configuration data can include configuration settings for modules with values ​​for file export, external display, performance logging, and system management operations. There can also be configuration data for imaging devices, such as configuration settings for supported imaging device models. There can also be tracking configuration data, which can include configuration settings for supported cameras. There can also be tracking jitter configuration data, including configuration settings for tracking jitter and noise reduction. There can also be log files, such as a system log file (e.g., named with a system startup timestamp as part of the filename). Session state data can be stored for session restore and includes data regarding available applications, selected imaging device model, brightness / contrast, and pan / zoom state. In one example, the session state data is stored more precisely in a session database or other data. Session data (e.g., data available for export) can include a session data directory containing screenshots and diagnostic files from different applications. Image bank file storage can be a directory of session-specific image bank images mapped to server file streams.

[0077] The monitor support engine 310 facilitates the use of multiple monitors on the cart 110. For example, the example shown in FIG. 1 illustrates the cart 110 with a primary monitor 160 and a secondary monitor 170. In one example, the monitor support engine 304 causes the primary monitor 160 to display a main screen user interface, including workflow navigation, setup, preoperative steps, intraoperative steps, and end procedure capabilities. The secondary monitor 170 can be controlled to display a secondary user interface, for example, during intraoperative workflow steps. The secondary user interface can include a navigation viewport and interface controls. The monitor support unit can support additional monitors beyond the primary monitor 160 and the secondary monitor 170. Such additional monitors can duplicate the content of the primary monitor 160 or the secondary monitor 170 or can provide different content. In an exemplary implementation, the directly supported interface for the additional monitors is a High-Definition Multimedia Interface (HDMI) or a Digital Visual Interface (DVI) through a port on the cart 110. If an additional monitor is connected, a resource tile, along with a corresponding label and settings icon, may appear on the primary monitor 160 or secondary monitor 170, allowing you to change what is displayed on that external monitor.

[0078] The local client profile engine 312 can control the management of one or more aspects of the local client 190. For example, the engine 312 can be defined with multiple different local client profiles from which a user may select. Exemplary local client profiles include a neurophysiologist profile, a sales representative profile, and an imaging technician profile. Depending on the profile selected, the user may be restricted from performing certain functions within the system 100 from the client device 190. In one example, the neurophysiologist and company representative (e.g., sales representative) profiles have full access to the functionality of the cart 110 from the client device 190. In one example, the neurophysiologist profile has access to intraoperative monitoring modalities, including stimulation. Certain types of stimulation, such as motor evoked potential monitoring, trilateral monitoring, and assessment program monitoring, may require remote stimulation settings to be enabled. In one example, the sales representative profile has access to all intraoperative monitoring modalities. For somatosensory evoked potential monitoring, motor evoked potential monitoring, trilateral monitoring, and assessment program monitoring, the sales representative can view stimulation results and adjust settings, but cannot initiate stimulation. The cart 110 may cause the client device 190 to prompt the neurophysiologist user for any changes to electrode settings, stimulation settings, and pre-initiation stimulation to confirm that they are working as required by the surgeon. In one example, an imaging technician profile is limited to imaging views and planning functionality, without the ability to perform intraoperative monitoring functions, including changing settings. Imaging technicians can be prevented from having access to navigation bend functionality. In some implementations, client profile restrictions are set using an authorization claims provider for the specific action in question. Each application can be responsible for defining each action and assigning the profile for which each action is authorized.These actions can be included in the permission model. User interface code can verify the availability of any of these actions using the claims provider interface. Examples of permissions and whether they are allowed for a particular profile are shown in Table I below. [Table 0001]

[0079] The audible information engine 324 facilitates audio playback. The system 100 can provide mute / unmute functionality and volume adjustment controls so that the system 100 can receive input from a user to adjust the system volume. The system 100 can provide volume control for the system 100 not only at the cart 110 but also at the local client device 190. Different sounds can have different priorities and behaviors. For example, if a sound is queued for a dynamic stimulus and there is a stimulation error, the stimulation error can interrupt all queued sounds and be played immediately. The audible information engine 324 can be configured to prevent lower priority sounds from interrupting higher priority sounds. The audible information engine 324 can be further configured to set a maximum amount of time a sound queues before being removed as stale (e.g., a sound waiting in the queue for longer than 500 milliseconds is removed as stale). In one example, the audible information engine 324 has rules for audio priority for errors and an additional rule that errors have the ability to interrupt when a sound of equal or lower priority is being played when a sound of the same priority is being played. In response to detecting actuation of the volume adjustment button 504, the system 100 presents the user with a system volume control including a list of modalities with an option to mute the entire system 100 as well as a toggle to turn audio on and off for each modality. If at least one modality is muted, the volume adjustment button can change to indicate that the sound is muted. If individual applications are muted and the system volume is muted, unmuting maintains the individual muted application settings.In one example, the audio output is monitored to ensure that the sound plays consistently through speaker 150, even if another device capable of playing audio (e.g., client device 190) is connected. Exemplary information regarding the types of sounds is shown in Table II. [Table 0002] The priority property can provide a way to both rank and group sounds. Queued sounds can be played in order, with the highest priority first. Queued sounds of the same priority are played first-in, first-out. Additionally, relative priorities can be used to determine when to interrupt a sound instead of queuing sounds using interruption rules. Loop can relate to whether to play a sound indefinitely until pause is called. Interruption rules can relate to when to interrupt a sound that is already playing. The queue on conflict property can relate to a sound that does not meet the conditions to interrupt another sound and indicates whether to queue the request, or else discard the request. The queue distinct property can indicate that only a single request of this audio type should be queued. The queue timeout property can relate to how long a request is allowed to remain in the queue before being played, if it is queued. The play on dequeue property can refer to logic used in a callback to ensure that if a request is queued, the sound should still be played when it is eventually dequeued. As illustrated above, different sound types can have different properties such as priority, loop, interrupt rule, queue on conflict, queue distinct, queue timeout, and play on dequeue, among others. Priority is a way to both rank and group sounds. Queued sounds can be played in order of highest priority. Queued sounds of the same priority can be played according to a first-in-first-out rule.Additionally, relative priorities can be used in determining when to interrupt a sound instead of queuing it using interruption rules. Loop can describe whether to replay a sound indefinitely until pause is called. Interruption rules can specify whether or when to interrupt a sound that is already playing. Conflict queue can describe whether to queue a request or discard a request if the sound request does not meet the conditions for interrupting another sound. The queue distinct property can indicate whether only a single request of this audio type should be queued. The queue timeout property can indicate how long a request should be allowed to be in the queue before playing. The play on dequeue property indicates the logic used in the callback to make sure the sound should still be played when it is eventually dequeued.

[0080] The timer engine 326 facilitates the use of timers. Multiple timers can be added to the system 100. Timer actions can be available in the system menu or from the timer button. Timers can be started / resume, stopped / paused, reset, and deleted. Timers can be used to time various aspects of a procedure.

[0081] The screen capture engine 328 can be configured to provide one or more users with the ability to capture screenshots (e.g., images or videos). In one example, capturing a screenshot involves capturing one or more screens based on how much of the screen is being used. For example, if an application utilizing the secondary monitor 170 is active, the capture mechanism can capture what is displayed on both the primary monitor 160 and the secondary monitor 170. In some examples, a screenshot is an image or video of a subset of the display area. In an exemplary implementation, screenshots are captured using the MICROSOFT DIRECTX graphics interface. In the event that this API fails, the system can be configured to fall back to using the WINDOWS GDI bit-block transfer mechanism to capture the screen. If the screenshots are images, they can be encoded in PNG format or another appropriate format and saved in the session data folder. In one example, the cart 110 can only capture the screen on the cart 110 itself, rather than what is displayed on the client device 190. If the screenshot action is triggered from the client device 190, the screenshot captures what is currently displayed on the cart 110, not what is on the client device 190. In another example, the screenshot configuration can take a screenshot of what is displayed on the client device 190, but not on the cart 110. In yet another example, the screenshot configuration captures what is displayed on all client devices and the cart 110.

[0082] The device engine 330 can control how multiple devices interact. In one example, devices are managed by back-end components. For example, an imaging device component can provide imaging device resources, an intraoperative monitoring component can provide patient module resources, and a tracking component can provide camera resources, which can then be consumed by other software (e.g., applications). A shared bus topic can be used to receive system resource information from loaded components. Components can register resources and then provide updates regarding connectivity and health status. Configuring individual resource settings can be the responsibility of each component. The cart 110 can communicate the connectivity and health status of each resource to a user interface. In one example, the device engine 330 can control the information displayed in the device section of a user interface, which will be described in more detail in connection with FIG. 5.

[0083] The local client support engine 332 is a component that supports the client device 190 . The cart 110 includes a local client access point 130 (e.g., a router) connected to the cart computer 120, which provides an access point for the local client 190 to connect to the cart 110. The local client access point 130 can be configured to provide one or both of wired and wireless connections. In one example, the access point 130 includes a hardware router. Access to the cart 110 through the local client access point 130 can be controlled through a connection passcode generated by the system 100 at runtime and displayed only on certain screens. The local client support engine 332 can be configured, for example, to control connections to the system 100 by the local client 190. The cart 110 can include multiple network interfaces (e.g., wired and wireless network interfaces) that can be connected to a hospital or other network to allow the cart 110 and locally connected clients to connect to the Internet. If both connections are established, the cart 110 can be configured to give one precedence (e.g., the wired connection). When the cart 110 is connected to the Internet, the connection can be shared to the local client 190. For example, the connection can be shared using the Internet connection sharing functionality in Windows. In another example, the Internet connection is made through the access point 130 to both the cart computer 120 and the client 190. In another example, the Internet connection is made from the hospital network to the cart computer 120, to the access point 130, and then to the client 190. If the Internet connection is changed from wired to wireless or vice versa, the Internet connection sharing can be updated to use the connection with Internet connectivity. If both have connectivity, the cart 110 can use the wired (e.g., Ethernet) connection. More information regarding the connection and use of the local client 190 is described in FIG. 7.

[0084] The imaging control engine 334 can be configured to provide functionality related to or data (e.g., images) obtained from the imaging device 182 coupled to the cart 110. The imaging control engine 334 provides, for example, the ability to select a desired imaging device model from a drop-down list of supported models, indicate the connected or disconnected status of the imaging device 182, show the current live view from the imaging device 182, pan or zoom to adjust the live image, reset the pan and zoom state to defaults, and provide controls to adjust image brightness and contrast settings.

[0085] The imaging control engine 334 can be configured to control the view imaging tab of a preoperative step during the preoperative or intraoperative portion of the workflow, display the current live view of the imaging with a live indicator, control pan and zoom, reset the pan and zoom state, adjust or reset brightness, adjust or reset contrast, save the current image to the image bank, load an existing image from the image bank, present an acknowledgement confirmation dialog to the client device user when an image is first saved to the image bank from each client, and convert an image to a return to live button that unloads and returns the view to the current imaging device live view in response to an image being loaded from the image bank. In one example, the imaging control engine 334 can open an alignment measurement screen and switch to dual view (e.g., live and reference) during the intraoperative portion of the workflow. When switching to dual view, the current live image is saved to the image bank and loaded into the reference view. The reference view offers the same pan / zoom, brightness / contrast, reset, and image bank access capabilities as the live view. When the imaging device display is in dual view, there is a copy to reference action button that, after activation, saves the current live image to the image bank and immediately loads it into the reference view.

[0086] The imaging control engine 334 can provide configuration for exporting imaging device images stored in an image bank to the imaging device during the termination portion of the workflow. These images can be set to be retained only until a new session is created or the session is older than 12 hours. The age of a session can be determined by subtracting the session's internal timestamp from the current time. The internal timestamp can be updated continuously (e.g., every 5 minutes) while the session is active.

[0087] The camera tracking engine 336 provides functionality related to tracking and navigation using the camera 180. The camera tracking engine may further provide functionality for setting up and configuring the camera 180. Exemplary functionality and techniques for providing camera functionality are provided in U.S. Patent Application Publication No. 2018 / 0092699, previously incorporated by reference herein.

[0088] The core software 220 further includes front-end components 350. The front-end components 350 can be components configured to provide the user interfaces described herein. Exemplary front-end components include, among others, an imaging device user interface component, a session user interface component, an image bank user interface component, an imaging component, a web shell component, a user interface utility component, and a tracking component.

[0089] The core software 220 further includes back-end components 360. The back-end components 360 can be components configured to provide back-end functionality. Exemplary back-end components 360 include, among others, an imaging device component, a platform component, a tracking component, an image framework component, a tracking component, and a network component.

[0090] The core software 220 may further include client-side frameworks and technologies that provide a full stack of plug-and-play capabilities for implementing desktop and browser-based applications (e.g., applications providing the surgical platform 210 applications and other functionality described herein). The framework may provide desktop web applications that feature or use an HTTP server such as NODEJS or KATAN and an embeddable web browser such as CHROMIUM EMBEDDED FRAMEWORK or JAVA / .NET CORE Web View. The client-side framework may extend that concept by adding plug-and-play functionality to the desktop and web shell to provide apps that can run on the desktop and as web applications. One or more components may be implemented using OWIN (Open Web Interface for .NET) components, which Microsoft built to target the traditional .NET runtime. KATANA, and by definition OWIN, allows middleware (OWIN-compliant modules) to be chained into a pipeline, thereby providing a modular approach to building web server middleware. For example, a client-side framework can use the Katana pipeline, which features modules such as SIGNALR, security, and the HTTP server itself. Plug-and-play capabilities can provide a framework that allows runtime assembly of apps from available plugins. An app built on top of a plug-and-play framework can have dozens of plugins, some providing infrastructure-level functionality and others providing domain-specific functionality. The CHROMIUM EMBEDDED FRAMEWORK is an open-source framework for embedding the CHROMIUM browser engine with bindings for different languages, such as C# or JAVA.OWIN is a standard for interfacing between .NET web applications and web servers that aims to sever the ties between ASP.NET applications and IIS by defining a standard interface.

[0091] Core software 220 can provide web components, which can be encapsulated, reusable, and configurable widgets for the web, as defined by the W3C Web Components specification. Within the context of core software 220, there are at least two types of web components distinguished by their level of reusability: custom web components and web plugins. Custom web components are reusable web components that are generic / generic and not bound to a specific product / domain. Web plugins are custom web components with a strong domain / product focus that are reusable only within the context of a family of apps. Web shell components can be empty shells that provide minimal plug-and-play support for other web components (e.g., web plugins). Web shells complement desktop shell components to provide a client framework. User interface components can include a client-side set of controls built, for example, on a JAVA, CSS, and HTML (JCH) development stack and a matching server-side set of web request handlers built, for example, on a .NET development stack. Client-side components may follow a pattern that enforces a separation between pure user interface structures that represent data (HTML and CSS controls) and JavaScript code for modeling data and behavior in the context of the view portion of the overall architecture, but this layer may have one or more properties that relate to web views in the view portion of the model-view-viewmodel paradigm.Logic (e.g., implemented in JAVASCRIPT®) can interact with the cart 110's Servo hosting software, for example, by either pulling data by triggering a server-side service (e.g., via RESET), pushing data to the server via WebSockets (e.g., via SIGNALR or other communication methods), and handling events from the server via similar communication methods (e.g., WebSockets or SIGNALR). Server-side logic (primarily Web request handlers and, in some cases, application event handlers) can be implemented in a manner similar to view models in the Model-View-ViewModel paradigm. Depending on the particular task at hand, these handlers can either invoke application layer services directly by retrieving instances of the required services from a service locator, or publish and receive messages (e.g., data) via a processing event bus.

[0092] Further exemplary techniques for implementing such computer functionality include frameworks and techniques provided by or in conjunction with programming languages ​​and associated libraries. For example, C, C++, C#, PYTHON®, JAVA, JAVASRIPT, RUST, assembly, HASKELL, other languages, or combinations thereof, can be used. Such languages ​​can include or be associated with one or more standard or community-contributed libraries. Such libraries, in the hands of those skilled in the art, can facilitate the creation of software based on the description herein, including receiving, processing, providing, and presenting data. Exemplary libraries for PYTHON and C++ include OPENCV (e.g., which can be used to implement computer vision and image processing techniques), TENSORFLOW® (e.g., which can be used to implement machine learning and artificial intelligence techniques), and GTK (e.g., which can be used to implement user interface elements). A further example includes NUMPY for PYTHON (e.g., which can be used to implement data processing techniques). In addition, other software can provide application programming interfaces that can be interacted with to implement one or more aspects described herein. For example, an operating system for a computing device (e.g., a Linux-based operating system such as WINDOWS by MICROSOFT CORP., MACOS® by APPLE Inc., or UBUNTU by CANONICAL LTD) or another component herein (e.g., a robot operating system such as IIQKA.OS or SUNRISE.OS by KUKA ROBOTICS CORPORATION where the robot is a model of KUKA ROBOTICS CORPORATION) may provide an application programming interface or library that can be used to implement aspects described herein.As a further example, a provider of a navigation system, laser console, or another component may provide not only hardware components (e.g., cameras or laser generators) but also software components (e.g., libraries, drivers, or applications) that can be used to implement configurations related to the component.

[0093] (Clinical Interface and Workflow) 4 illustrates a typical clinical workflow 400 in which the cart 110 (and its core software 220) is used. As shown, the clinical workflow 400 includes a system initiation operation 420, a system setup operation 430, a pre-operative operation 440, an intra-operative operation 450, and a finish procedure operation 460.

[0094] The system startup operations 420 include one or more operations that prepare the system 100 for use. As shown, the system startup operations 420 include a connect to network operation 422, a connect local client operation 424, a start session operation 426, and a start remote monitoring operation 428.

[0095] The network connection operation 422 includes one or more operations that cause one or more components of the system 100 to gain access to the network 20. The operation 422 may include, for example, forming a wired connection between a component of the system 100 and a network access point (e.g., connecting an Ethernet wall jack and an Ethernet port of the component of the system 100 using an Ethernet cable). For example, the operation 422 may include connecting the cart computer 120 to a local area network provided by a hospital by connecting an Ethernet cable between the external interface 140 of the cart computer 120 and a registered jack network interface (e.g., RJ45) provided in the operating room 10. In another example, the local client access point 130 is connected to an interface provided in the operating room rather than the cart computer 120. In another example, the operation 422 may include forming a wireless connection by connecting the component of the system 100 to the network 20 using a wireless protocol (e.g., a wireless radio frequency protocol), such as, for example, BLUETOOTH®, WIFI, or cellular (e.g., 5G). Operation 422 may further include one or more operations related to authenticating to the network (e.g., via providing one or more appropriate credentials, passwords, or usernames) and performing a networking handshake.

[0096] A local client connect operation 424 includes one or more operations that cause one or more client devices 190 to connect to one or more other components of system 100 or networks connected in operation 422. An exemplary process for connecting a local client device 190 is described in more detail in connection with FIG.

[0097] A start session operation 426 may include initiating a session for use in performing a procedure (or conducting training or testing related to using system 100 in performing a procedure). Operation 426 may include configuring and launching one or more software components (e.g., the software components described above) for use in the procedure. In one example, before or during operation 426, system 100 receives from a user an indication of the type of procedure to be performed, the anatomical location where the procedure will be performed (e.g., cervical anatomy, thoracic anatomy, or lumbar anatomy), and the approach to be used (e.g., anterior, lateral, or posterior).

[0098] The initiate remote monitoring operation 428 may include performing one or more operations to enable remote monitoring of one or more components of the system 100. For example, the system 100 may support remote neuromonitoring. During remote neuromonitoring, one or more components of the system 100 may provide neuromonitoring data to a remote party and receive data in response. For example, the remote monitoring may include NUVAREMOTE, such as that offered by NUVASIVE, INC. In one example, a neuromonitoring local client device 190 with an internet connection established through the cart 110 connects to a remote server associated with a remote neuromonitoring service (e.g., NUVAREMOTE by NUVASIVE). As part of the connection, the local client device 190 may obtain credentials or other data from the user used to authenticate the user and provide them to the service.

[0099] The system setup operation 430 can include one or more operating actions that set up the system 100100 for use in a surgical procedure. In one example, the operation 430 can include providing a start-up user interface, as shown in FIG.

[0100] FIG. 5 shows an exemplary startup user interface 500. The startup user interface 500 can provide the cart 110 with the ability to receive user selection of one or more anatomical regions of the spine and one or more surgical approaches (e.g., an anterior, lateral, or posterior spinal approach). The available selections can be defined in a configuration file. The core software 220 can create intraoperative tabs for each approach to help define and control workflow through various stages of a surgical procedure and provides anatomical selections for each of the included applications to provide option availability and default settings. The startup user interface 500 includes a menu button 502 actuable to provide a menu, a volume button 504 actuable to allow the user to change the volume of the cart 110, and a network button 506 actuable to allow the user to change the network settings of the cart 110. The startup user interface 500 includes a devices section (e.g., a devices region) 510. The devices section 510 provides one or more user-actuable buttons that a user can use to connect and configure one or more devices connected to the cart 110, such as the camera 180, imaging device 182, or client device 190. In some implementations, the devices section 510 displays only connected remote client devices (which may or may not be configurable from this user interface 500). In one example, connected devices, such as the camera 180 or imaging device 182, are visible or configurable only after a session has begun. The start-up user interface 500 further shows buttons that a user can actuate to select an anatomy, select an approach, and begin a session.

[0101] FIG. 5 further illustrates a device region 510 that can be controlled by the device engine 330 to represent different devices within separate device icons (e.g., device tiles) 512. The device engine 330 can control the device region 510 and header row, icons, and labels to, for example, provide a “needs attention” indication (e.g., via color) when additional action is required and an “all set” indication when no additional action is required. Each different device can be represented by a separate device icon 512. In some examples, the device region 510 includes devices that represent additional display interfaces (e.g., laptops, tablets, and monitors) as separate from other devices (e.g., neuromonitoring devices or imaging devices) within the device region 510. When a device is disconnected, the background color of its device icon 512 can provide a “needs attention” indication. In some examples, one or more of the device icons 512 can include a “required” flag, depending on the connection status of one or more applications selected and dependent devices. When a connected device has initialization or communication issues, a warning icon may appear in the patient module in the lower right corner. This indicates that the physical connection is complete, but there is an error. Pressing the device with the alert icon may launch a tool tip message box. The tool tip message box may contain text related to the specific error detected. In some examples, the device area 510 or elsewhere may provide information about the connection status between the client device 190 and the cart 110. For example, the device area 510 may show a good wireless signal level indicator (e.g., color-coded green) when the round-trip latency of the signal between the connected device and the cart 110 is less than 300 milliseconds.The device area 510 shows a caution wireless signal level indicated (e.g., color-coded yellow) when the round-trip latency of the signal between the connected device and the cart 110 is greater than 300 milliseconds for a time period less than 5 seconds. The device area 510 shows a warning wireless signal level indicator (e.g., color-coded red) and can display a message indicating that the client has disconnected from the cart 110 when the round-trip latency of the signal between the connected device and the cart 110 is greater than 300 milliseconds for more than 5 seconds.

[0102] FIG. 5 provides an example in which one of the icons is a camera, such as an infrared tracking camera for use in navigation, imaging, and bending applications, among others. Whenever at least one application that relies on a camera is enabled (e.g., bending, imaging, or navigation), a camera device icon 512 can be shown in the device area 510. When a camera is needed but not connected, the camera device icon 512 can provide such an indication (e.g., by being red). When a camera is connected and initialized, the tile can provide such an indication (e.g., by changing from red to gray). When a camera is connected and powered on, an audio tone is played by the camera and a green LED is illuminated on the camera. The device icon 512 can include a settings button 514. After detecting activation of the settings button 514, the system 100 can launch a camera setup dialog that provides the ability to switch between a live view (e.g., infrared video from the camera) and an array view (display of markers visible to the camera). While in camera view, no tracking data is available to the application for markers or rigid bodies. While in array view, the right side of the camera setup can provide a display of the rigid bodies being tracked and where they appear within the working volume of the camera. An example of this is shown in Figure 6.

[0103] 6 shows a camera setup user interface 600. User interface 600 includes menu button 502, a power button 602 operable to display power information, volume buttons 504, a camera button 604, a network button 506, a timer button 606 operable to display a timer menu, and an applications button 630. User interface 600 further includes a camera viewer that displays a representation of one or more markers visible to the camera and an estimated representation of the camera's field of view. Such information can facilitate camera calibration and setup.

[0104] Returning to FIG. 5 , the device region 510 further illustrates an imaging device, such as a C-arm. The system 100 can support the import of radiographic images from the imaging device 182. In an exemplary implementation, the system 100 can support a variety of different types of imaging devices 182. The system 100 can receive a selection of an imaging device type from a user to match the connected imaging device. The selection received from the user can be used to associate specific parameters for importing images from the connected image stream. The captured images can be provided to the imaging device engine or the specific application requesting the image capture. The system 100 can use, for example, an off-the-shelf frame grabber capture card. The capture card can be connected to the imaging device, for example, through a DVI or HDMI connection. The cart 110 can acquire images from the imaging device 182 through this connection.

[0105] 5 further shows an external monitor in the devices area 510. If an external monitor is connected to the cart 110, a corresponding device tile can appear in the devices area 510. Such a device tile 512 can include a settings button 514 that presents a dialog for controlling which screens should be duplicated on the connected monitor. In one example, the default setting can be that the secondary screen is duplicated on the external display.

[0106] Returning to FIG. 4, as shown, operations 430 may include a camera setup operation 432 , an imaging device setup operation 434 , and a setup timer operation 436 .

[0107] The camera setup operation 432 may include connecting and positioning the camera 180. In some examples, during the camera setup operation 432, the cart 110 may provide a user interface configured to facilitate camera setup, as shown in FIG.

[0108] The imaging device setup operation 434 may include connecting and verifying the imaging device 182. For example, the operation 434 may include connecting the imaging device 182 to one or more of the external interfaces 140 and performing one or more setup operations on the imaging device 182.

[0109] The setup timer operation 436 may include performing one or more operations including initializing one or more timers.

[0110] Pre-operative operations 440 include performing one or more operations prior to performing a surgical procedure. As shown, operations 440 can include an imaging device verification operation 442. Imaging device verification operation 442 can include verifying one or more display settings associated with imaging device 182.

[0111] The intraoperative operation 450 includes one or more operations that are performed during surgery. As shown, the intraoperative operations 450 include an application view switch operation 452, an input event operation 454, and a start / stop timer operation 456.

[0112] The application view switching operation 452 includes switching between one or more applications provided by the system 100. For example, the operation 452 may include switching between neuromonitoring, planning, navigation, imaging, and bending software in response to received user input. While providing an application, the application may provide one or more configurations or functions provided by the application to assist the healthcare professional in performing the procedure. The application may continue to run as a background application.

[0113] Input event operations 454 include receiving and recording one or more surgical events from a user or components of system 100. For example, system 100 may receive from a user one or more text annotations (e.g., user-specified text entered into an input field or text generated by a speech-to-text system based on voice input from the user), one or more selected predefined surgical events (e.g., receiving a selection of one or more surgical events from a predefined list of specific surgical events available from a drop-down menu or other user interface element), or triggered events (e.g., specific events that may be triggered based on activity during a session, such as neurostimulation).

[0114] A start / stop timer operation 456 includes starting or stopping one or more timers (e.g., one or more timers set in operation 436). Starting or stopping a timer can be controlled based on user input received at the cart 110 or the client device 190.

[0115] The end procedure operation 460 includes performing one or more procedure wrap up operations. As shown, the operation 460 includes an export data operation 462 and an assign case identified operation 464.

[0116] The export data operation 462 can include performing one or more operations to export data obtained during surgery. For example, the data can be a log file and one or more images acquired.

[0117] An assign case identifier operation 464 may include assigning a case identifier to the surgical case.

[0118] As discussed above, method 400 may include a system initiation operation 420 that may include a connect local client operation 424. That operation 424 is described in more detail in method 700 of FIG.

[0119] (Client device wireless connection workflow) FIG. 7 illustrates an example method 700 for connecting one or more local client devices 190 to a cart 110, such as may be performed in operation 424 of FIG.

[0120] Operation 702 includes determining a network name 922 for use with the client network 132. Operation 702 can be performed by the cart 110 (e.g., its cart computer 120). The network name 922 can be a service set identifier (SSID) for networks created based on the IEEE 802.11 standard. Determining the network name 922 can include loading a predetermined network name 922, receiving a network name 922 specified by a user, receiving a network name 922 specified by the local client access point 103, or obtaining the network name 922 from a network name generator. For example, the network name generator can be an algorithm running on the cart computer 120 that generates the network name 922 based on one or more criteria. For example, the algorithm can generate the network name 922 to include certain standard components (e.g., the current date, the name of the current operating room, the name of the hospital, or other components) as well as one or more generated components (e.g., a predetermined fixed-length or variable-length pseudo-generated code).

[0121] Operation 704 includes determining a password 924. Operation 704 can be performed by the cart 110 (e.g., its cart computer 120). For example, determining the password 924 can include loading a pre-defined password 924, receiving a password 924 specified by a user, receiving a password 924 specified by a local client access point 103, or obtaining the password 924 from a password generator. For example, the password generator can be an algorithm running on the cart computer 120 that generates the password 924 based on one or more criteria (e.g., length, complexity, or style). For example, the algorithm can generate the password 924 from artificially selected letters, numbers, symbols, or words.

[0122] Operation 706 includes determining a Uniform Resource Locator (URL) 926. Operation 706 can be performed by the cart 110 (e.g., its cart computer 120). For example, determining the URL 926 can include loading a pre-defined URL 926, receiving a URL 926 specified by a user, or obtaining the URL 926 from a URL generator. For example, the URL generator can be an algorithm running on the cart computer 120 that generates a URL based on one or more criteria (e.g., local resource location).

[0123] Operation 708 includes determining a code 928. Operation 708 can be performed by the cart 110 (e.g., its cart computer 120). Determining the code 928 can include loading a pre-defined code 928, receiving a user-specified code 928, or obtaining the code 928 from a code generator. For example, the code generator can be an algorithm running on the cart computer 120 that generates the code 928 based on one or more criteria (e.g., length, complexity, or style). For example, the algorithm can generate the code 928 from artificially selected letters, numbers, symbols, or words. In one example, the code 928 is different from a password. For example, the password 924 is a password for the client network 132, and the code 928 is used to access resources provided by the cart 110 after the client device 190 is connected to the wireless client network 132. In an exemplary implementation, a local client 190 with connectivity to the client network 132 can connect only after entering a code 928 that is displayed on a monitor (e.g., primary monitor 160) of the cart 110. The code 928 can be regenerated at least once each time the cart 110 is started and for a specified period of time (e.g., 24 hours) while it is running. When a user connects from a local wireless client 190, the user may be prompted to provide a username, which is entered along with the code and written to a log file along with a unique ID generated for that user.

[0124] Operation 710 includes providing a network configuration user interface 800. Operation 710 can be performed by the cart 110 (e.g., its cart computer 120). For example, the cart computer 120 can provide the network configuration user interface 800 on a display (e.g., the primary monitor 160) of the cart 110. In one example, the cart computer 120 uses the host software 202 to host a page having the network configuration user interface 800. The cart computer 120 launches the browser 192 by executing browser code and causes the browser 192 to render the network configuration user interface 800 by connecting to an address (e.g., as specified by a URL) corresponding to the hosted page. The network configuration user interface 800 is a set of one or more user interfaces that provide network configuration information for a user to use in connecting one or more client devices 190. An exemplary wired network configuration user interface 800 is shown in FIG. 8. An exemplary wireless network configuration interface is shown in FIG. 9.

[0125] FIG. 8 illustrates an exemplary wired network configuration user interface 800, including a network configuration interface 810. The network configuration interface 810 includes multiple connection selectors 812, 814, an advanced selector 816, a status section 818, and an instruction section 820. The connection selectors 812, 814 include a wired connection selector 812 and a wireless connection selector 814. As shown, the selected wired connection selector 812 indicates that a wired connection has been selected. The wireless connection selector 814 is a selector that, upon activation, causes the display of the wireless network configuration interface 900. The advanced selector 816 is a user-actuable control that, when activated, causes the display of advanced networking configurations. The status section 818 indicates the status of various network aspects, such as the current state (e.g., connected or not connected), the currently used adapter (e.g., Ethernet, Wi-Fi, or Bluetooth), and the IP address. The instruction section 820 provides instructions to the user on how to connect the client device 190. In the illustrated example, the command is to connect a network cable.

[0126] FIG. 9 illustrates an exemplary user interface 800 including a network configuration interface 810. The network configuration interface 810 includes multiple connection selectors 812, 814, an advanced selector 816, a status section 818, and an instruction section 820. The connection selectors 812, 814 include a wired connection selector 812 and a wireless connection selector 814. Here, the wireless connection selector 814 indicates that a wireless connection has been selected. The instruction section 920 shows instructions for connecting the client device 190. As shown, the instructions include disconnecting the client device 190 from an existing network, connecting the client device to a wireless network having a network name 922, entering a password 924, such as a password for the wireless network, navigating to a URL 926, and entering a code 928 on the resulting page. The network name 922, password 924, URL 926, and code 928 can be populated based on data determined during operations 702, 704, 706, and 708.

[0127] Returning to FIG. 7 , operation 711 includes provisioning a wireless network, such as client network 132. For example, client network 132 can be provisioned using local client access point 130. Client network 132 can be provided with a name (e.g., SSID) set in name 922. Client network 132 can support encrypted communications using password 924 (e.g., using the WPA-2 protocol). In some examples, provisioning client network 132 can include adjusting the power of the wireless network (affecting the range of the wireless network) to expand coverage to cover operating room 10 without providing significant additional coverage beyond operating room 10. The cart computer 120 can cause the local client access point 130 to provision client network 132 (e.g., by sending a command to the local client access point 130). In another example, the local client access point 130 can automatically provision client network 132 in response to initiation. The local client access point 130 may include instructions that, when executed by one or more processors of the local client access point 130, cause the local client access point 130 to provide a wireless network. The client network 132 may be provided according to a standard wireless protocol, such as WI-FI, BLUETOOTH, ZIGBEE, or other protocol.

[0128] Operation 712 includes hosting a type page 713. For example, the cart 110 can host the page 713 at an IP address. The cart 110 can host the page 713 by a cart computer 120 executing host software 202 such that the page 713 is provided at an IP address. The page 713 can be a type page 713 that provides one or more selectable user interface elements (e.g., buttons or menus) representing different user types. For example, the user types can be a neurophysiologist type, a representative type, or an imaging technician type, among others. Different client devices 190 can be operated by different users, and selecting a user type can facilitate customizing the user experience to suit the user. The type can further limit functionality to the user type.

[0129] Operation 713 includes the client device 190 connecting to the client network 132. For example, the client device 190 receives user input navigating to a wireless network settings interface of the client device 190 and receives a selected wireless network having a network name 922. The client device 190 may further receive a password 924 from the user. In some examples, the client device 190 has the network name 922 and password 924 saved, and the connection is initiated automatically. The user may obtain the network name 922 and password 924 by viewing the display of the cart computer 120 (e.g., as provided in operation 710) and then manually selecting the network name 922 from a list of available networks and providing the password 924 at the password prompt. Once the network name 922 and password 924 are available for use in connecting, the client device 190 and the local access point 130 may perform a network handshake to establish a connection between the client device 190 and the local client access point 130. In an alternative implementation, one or more of the password 924 and network name 922 are provided as part of a machine-readable code (e.g., a QR code) displayed by the cart 110. When the client device 190 scans the code, one or more of the steps of connecting to the network 132 can be automated based on the information obtained via the code.

[0130] Operation 714 includes navigating to URL 926. In one example, the URL is received as input from a user in an address field of a web browser 192 running on client device 190. In one example, browser 192 is a CHROMIUM-based browser. In one example, operation 714 includes launching browser 192.

[0131] Operation 716 includes the cart 110 resolving the URL to an IP address associated with the page. For example, the cart 110 may include its own domain name service that associates URLs with IP addresses associated with pages. For example, the cart computer 120 may run a domain name service (e.g., using BIND by ISC). The cart 110 receives the URL 926 navigated by the web browser 192 over the network 132 and then uses the domain name service to resolve the received URL to an IP address. The IP address that the client device (e.g., its browser 192) accesses to retrieve the page 713 may be provided to the client device 190. In some implementations, the domain name service is configured to redirect traffic from URLs other than URL 926 to a public DNS (e.g., such as provided by GOOGLE, CLOUDFLARE, or OPENDNS) so that navigation to other websites works as expected. For example, the domain name service may be configured to do so via one or more configuration files that define one or more URLs and address ranges.

[0132] Operation 718 includes providing the type page 713 to the client device 190. In some examples, the type page 713 is provided over an HTTPS connection. The content of the page 713 provided over the connection between the client device 190 and the cart 110 via the network 132 may include content provided by the system cart software 200. The hosting software 202 may provide the type page 713 to the client device 190.

[0133] Operation 720 includes receiving a user type at client device 190 via page 713. For example, client device 190 receives the page and browser 192 renders type page 713 for the user. As described above, page 713 may include one or more selectable user interface elements (e.g., buttons or menus) representing different user types. Client device 190 may receive a selection of one or more of the different user types. The selection is provided to cart 110 over network 132.

[0134] Operation 722 includes the cart 110 receiving the user type. For example, the cart 110 can detect the activation through a connection with the client device 190, such as by receiving a communication from the client device 190 indicating that a particular user type has been selected.

[0135] Operation 724 includes providing a confirmation page 725 to the client 190. The confirmation page 725 can be selected or generated based on the received user type. The confirmation page 725 can include a prompt, an affirmative button, and a negative button, among other components. The cart 110 may require selection of the affirmative button before proceeding. In one example, the prompt can vary depending on the user type received in operation 722. In response to the user type being a representative or imaging technician, the prompt can indicate that the user acknowledges that by selecting the affirmative button, they are operating at the direction of a physician. In response to the user type being a neurophysiologist, the prompt can ask the user to confirm that they are a trained neurophysiologist with appropriate qualifications to facilitate intraoperative neuromonitoring for surgical procedures. In some examples, there can be multiple prompts requiring a response before continuing. In one example, the prompt asks the user to acknowledge that protected health information will not be entered or saved in the cart 110. The system may prevent the client device 190 from continuing the process until a positive recognition occurs.

[0136] Operation 726 includes the client device 190 receiving the confirmation page 725 from the cart 110. The client device 190 may render the confirmation page 725 in the browser 192. While rendering the confirmation page 725, the client device 190 detects activation of the yes or no button and sends an indication of the activation to the cart 110.

[0137] Operation 728 includes the cart 110 receiving a yes or no button activation. In response to detecting a no button activation, the cart 110 can provide an error or prevent further access until a yes button is activated. In response to receiving an indication of a yes button activation, the cart 110 can provide a code page for receiving a code as described in operation 730.

[0138] Operation 730 includes providing a code page 731 configured to receive the code. For example, the code page 731 may include a text box or other user interface element configured to receive the code from the user and provide the input to the cart 110 for processing. The cart 110 provides the code page 731 to the client device 190 for rendering in the browser 192.

[0139] Operation 732 includes the client device 190 receiving the code page from the cart 110 and rendering the code page. The client device 190 may receive input from a user of the code. The client device 190 then provides the received code to the cart 110.

[0140] Operation 734 includes the cart 110 receiving the code obtained in operation 732. The received code is then compared to code 928. In response to a matching code, the cart 110 may proceed to operation 736, where it provides the service. In response to a non-matching code, the cart 110 may cause the client device 190 to display an error indicating that an incorrect code was provided.

[0141] In some examples, the cart 110 provides a local client warning message to be displayed on the local client device 190 under certain circumstances to prevent the user from continuing. In one example, the message provided is a system stopped message in response to the cart 110 stopping. In another example, in response to the number of clients connected to the cart 110 exceeding a predetermined limit of client connections, the cart 110 can provide a message indicating that the number of connected devices has been exceeded and that in order to connect the client device 190, another connected device should first be disconnected.

[0142] The operation 736 includes the cart 110 providing a service. For example, the service may include providing the client device 190 with access to the configuration of the surgical platform 210 through the browser 192. For example, the cart 110 may use the hosting software 202 to provide access to services and applications offered by the surgical platform 210. The same or different services may be provided to a direct user of the cart 110, such as a user operating an input device on the cart 110 and viewing the output of the cart on one or both of the primary monitor 160 and secondary monitor 170.

[0143] In some examples, the cart 110 has a browser 204 that connects to hosting software 202 that the cart 110 uses to provide the server, and direct users of the cart 110 can access the service through the browser 204 of the cart 110.

[0144] In some examples, method 700 further includes providing Internet (or other network, such as network 20) ​​connection sharing from cart 110 to client device 190. For example, client device 190 can access the Internet via the connection between device 190 and cart 110.

[0145] Operation 738 includes the client device 190 interacting with the provided service. For example, during operation, a user may operate the client device 190 to access one or more aspects of the surgical platform 210 to facilitate a surgical procedure using the browser 192.

[0146] In some examples, the core software application changes all instances of a workflow step (e.g., setup, pre-op, intra-op, or close) on one or more client devices 190 and cart 110 when the current workflow step is changed on the client device 190 or cart 110. The core application can prevent access to another workflow step until affirmative acknowledgment is received through the user interface.

[0147] (User Interface) FIG. 10 shows an exemplary intraoperative page 1000 being rendered within the web browser 192 of the client device 190. Such a page 1000 may also be rendered within the browser 204 of the cart 110. While the web browser 192 is shown with an address bar and menu, such user interface elements can be hidden (e.g., in full-screen view) so that more screen real estate is dedicated to the intraoperative page 1000. The intraoperative page includes a left panel 1010 and a right panel 1020. The panels 1010, 1020 include buttons 1012 that, when activated, close the panels 1010, 1020 and display a default view. The intraoperative page 1000 further includes an application selector 630. In response to being activated by the user, the application selector 630 provides a menu 1030 from which the user can select an application to be displayed in the left panel 1010 using one or more buttons 1032, each representing an application to launch. In response to a new application being selected, the current view (eg, in the left or right panel 1010, 1020) is closed and a new view corresponding to the new application is provided in the panel.

[0148] Among the buttons 1032 is a button 1034 that closes all open application views and displays a default view. For example, the default view can be a view that displays a default imaging view in the left panel 1010 and a neuromonitoring view in the right panel 1020. The button 1034 can be equivalent to closing an existing application. In some examples, in response to a user interface element being activated in the left or right panel 1010, 1020, a corresponding view is caused to open in the opposite panel 1010, 1020. For example, the right panel 1020 can show a neuromonitoring view with a waveform view button that, when activated, causes the waveform view to be displayed in the left panel 1010.

[0149] When the intraoperative page 1000 is displayed on the client device 190 , there may be a button that causes the client device 190 to show what is displayed in the cart 110 .

[0150] In one example, the left panel 1010 has a default view of the imaging device (eg, the view from the C-arm).

[0151] While various descriptions of aspects of the present disclosure may refer to a surgeon or surgeons, it should be understood that the functionality of such aspects may extend to other users, as contextually appropriate, such that the term “surgeon(s)” supports the term “user(s).” In some examples, the surgeon can be a surgical robot.

[0152] Examples herein include methods that include operations. While the operations in the figures are shown in sequential order, the operations may, in some examples, be performed in parallel and / or in orders different from those described herein. Also, various operations may be combined into fewer operations, split into additional operations, and / or eliminated, based on the desired implementation.

[0153] Additionally, the diagrams may illustrate the functionality of possible implementations. An operation may represent a module, segment, or portion of program code, which comprises one or more instructions executable by one or more processors (e.g., CPUs) to implement particular logical functions or steps in a process. The program code may be stored on any type of computer-readable medium, such as storage devices including, for example, disks or hard drives. The computer-readable medium may include non-transitory computer-readable media that store data for short periods of time, such as register memory, processor cache, or random access memory (RAM), and / or persistent long-term storage devices, such as, for example, read-only memory (ROM), optical or magnetic disks, or compact disc read-only memory (CD-ROM). The computer-readable medium may be or include any other volatile or non-volatile storage system. The computer-readable medium may be considered, for example, a computer-readable storage medium, a tangible storage device, or other article of manufacture. The computer-readable medium may be communicatively coupled to one or more processors. The one or more processors may be coupled to one or more interfaces to provide data to or receive data from one or more users or other devices. Exemplary interfaces include a universal serial bus, a display, a speaker, a button, a networking component (e.g., a wired or wireless networking component), other interfaces, or a combination thereof.

[0154] The operations may represent circuitry that is hardwired to perform particular logical functions in a process. The illustrated methods may be performed, in whole or in part, by a component or multiple components within the cloud and system. However, it should be understood that the exemplary methods may instead be performed by other entities or combinations of entities (e.g., by other computing devices and / or combinations of computer devices) without departing from the scope of the present invention. For example, particular operations may be performed entirely by a computing device (or a component of a computing device, such as one or more processors), or may be distributed across multiple components of a computing device, across multiple computing devices, and / or across servers.

Claims

1. During surgery in the operating room or in preparation for said surgery, using a computer on a surgical cart located within the operating room; Determining a network name; Deciding on a password; determining a uniform resource locator; Determining the code; providing a network configuration user interface on a monitor of the computer showing the network name, the password, the uniform resource locator, and the code; hosting a first web page at an internet protocol address; providing a wireless network with an access point on the surgical cart, the wireless network having the network name and protected using the password; using a first client device located in the operating room during or in preparation for the surgery; connecting to the wireless network using the network name and the password; Launch a web browser and navigating the web browser to the uniform resource locator; using the computer on a surgical cart located in the operating room; detecting navigating the web browser to the uniform resource locator; translating the uniform resource locator into the internet protocol address where the first web page is hosted; providing the first web page to the first client device, the first web page including at least one user interface element; using the first client device located in the operating room; Rendering the provided first web page in the web browser; receiving user input representing the code through the at least one user interface element of the first web page in the web browser; providing the user input to the computer of the surgical cart; using the computer of the surgical cart; receiving the user input representing the code from the first client device; determining a match between the code and the user input representing the code; During the surgery, using the computer on the surgical cart, after determining the match between the code and the user input representing the code, providing a first surgical application to a first user via the web browser of the first client device based on an interaction from the first client device; providing a second surgical application to a second user via the monitor of the surgical cart. method.

2. using the computer on the surgical cart located in the operating room during or in preparation for the surgery; connecting the computer of the surgical cart to the Internet; sharing the connection to the Internet from the surgical cart to the first client device; During the surgery, using the first client device located in the operating room, accessing the Internet from the first client device through the shared connection; The method of claim 1.

3. The method of claim 2 , wherein accessing the Internet from the first client device through the shared connection includes accessing a remote neuromonitoring service via the Internet.

4. The method of any one of claims 1 to 3, further comprising concurrently hosting the first surgical application and the second surgical application using hosting software on the computer.

5. determining, using the computer on the surgical cart located in the operating room, a role of the first user of the first client device during or in preparation for the surgery; Providing the first surgical application to the first user based on the role; Determining the role of the first user of the first client device includes: using the computer on the surgical cart located in the operating room during or in preparation for the surgery; providing a second page to the web browser, the second page including one or more selectable user interface elements representing different user types; determining a user interface activation of at least one of the one or more selectable user interface elements corresponding to the role; The method according to any one of claims 1 to 4.

6. The method of claim 5 , wherein the user types are selected from the group consisting of neurophysiologists, company representatives, and imaging technicians.

7. 7. The method of claim 1, wherein the first surgical application and the second surgical application are different surgical applications selected from the group consisting of a neuromonitoring application, a planning application, a navigation application, an imaging application, and a rod bending application.

8. providing the second surgical application to the second user via the monitor of the surgical cart; accessing the second surgical application using a web browser running on the computer of the surgical cart. The method according to any one of claims 1 to 7.

9. 1. A system including a surgical cart, The surgical cart includes: a local client access point; A primary monitor; a cart computer, the cart computer comprising: one or more processors; Memory and a plurality of external interfaces, the plurality of external interfaces comprising: a first external interface coupled to the local client access point; a second external interface coupled to the primary monitor; The memory includes instructions that, when executed by the one or more processors, cause the one or more processors to: Determine the network name Decide on a password, Determine the uniform resource locator, Determine the code, providing a network configuration user interface showing the network name, the password, the uniform resource locator, and the code; hosting a first web page at an internet protocol address; detecting a web browser of a first client device navigating to the uniform resource locator; causing the uniform resource locator to be resolved into the internet protocol address at which the first web page is hosted; causing the first web page to be provided to the first client device, the first web page including a user interface element; receiving a user input representing the code from a client device; determining a match between the code and the user input representing the code; after determining the match between the code and the user input representing the code, causing a first surgical application to be provided to a first user via the web browser of the first client device based on an interaction from the client device; providing a second surgical application to a second user via the primary monitor of the surgical cart; the local client access point includes instructions that, when executed by one or more processors of the local client access point, cause the local client access point to provide a wireless network having the network name and protected using the password; system.

10. 10. The system of claim 9, wherein the memory further comprises instructions that, when executed, cause the one or more processors to share an Internet connection from the cart computer to the client device.

11. The memory further includes instructions that, when executed, cause the one or more processors to determine a role of the first user of the client device; providing the first surgical application to the first user based on the role; 11. A system according to claim 9 or 10.

12. Determining the role of the first user of the client device includes providing the web browser with a second page including one or more selectable user interface elements representing different user types; determining an activation of at least one user interface element of the one or more selectable user interface elements corresponding to the role; The system of claim 11.

13. The system of claim 12 , wherein the user types are selected from the group consisting of neurophysiologists, company representatives, and imaging technicians.

14. 14. The system of claim 9, wherein the first surgical application and the second surgical application are different surgical applications selected from the group consisting of a neuromonitoring application, a planning application, a navigation application, an imaging application, and a rod bending application.

15. a first client device; a second client device connected to the local client access point; a third client device connected to the local client access point; A system according to any one of claims 9 to 14.

16. An imaging device; a camera; and A system according to any one of claims 9 to 15.

17. the cart computer is disposed within a cart computer housing; the local client access point is located in a client access point housing separate from the cart computer housing; A system according to any one of claims 9 to 16.

18. 20. The system of claim 17, wherein the local client access point is coupled to the cart computer via an Ethernet cable.

Images