Medical image transfer system

Abstract

To provide a transfer module that is useful for: image-guided surgery (IGS) navigation systems having no preexisting wireless capabilities; and those having wireless capabilities that are less secure than those provided by the modified IGS navigation system.SOLUTION: The invention provides a transfer module having wireless communication capabilities attached to an IGS navigation system. Images, videos and data stored on the IGS navigation system are moved to and stored on the transfer module in an encrypted format. The transfer module connects to a secure network or other secure wireless communication, and transfers encrypted IGS medical procedure data to a physician device, a hospital system device, or other device. After validation, the physician device or other device may decrypt and display the data.SELECTED DRAWING: Figure 4

Description

[Background technology]

[0001] Image-guided surgery (IGS) is a technique that uses a computer to obtain real-time correlation of the location of an instrument inserted within a patient's body to pre-operatively or intra-operatively obtained images (e.g., CT or MRI scans, 3D maps, etc.) such that the computer system can overlay the current location of the instrument onto the pre-operatively obtained images. In some IGS procedures, one or more digital images (e.g., still and / or video images) of the field of operation are acquired. This may include a digital tomographic scan (e.g., CT or MRI, etc.) of the operative field obtained prior to surgery. Additionally or alternatively, digital images may be obtained via ultrasound or diagnostic catheters, fluoroscopy, and / or other devices and techniques. A specially programmed computer is used to convert the digital tomographic scan data and / or other image data into a digital map. During surgery, specialized medical instruments (e.g., catheters, guidewires, etc.) having sensors (e.g., one or more coils that respond to externally generated electromagnetic fields) mounted thereon are used to perform the medical procedure while the sensors send signals to a computer indicating the current location of the associated medical instrument. The computer correlates the data received from the instrument-mounted sensors with a digital map created from the pre-operative tomographic scan. The tomographic scan images are displayed on a video monitor along with indicators (e.g., crosshairs or illuminated dots, etc.) indicating the real-time location of each surgical instrument relative to the anatomical structures shown in the scan image. This allows the surgeon to know the exact location of each sensor-equipped medical instrument by viewing the video monitor, even if the medical instrument itself cannot be directly viewed at its current location within the body.

[0002] An example of an electromagnetic IGS system that can be used in cardiac electrophysiology is the CARTO® 3 System by Biosense-Webster, Inc. (Irvine, California). When applied to various procedures, such as catheter ablation, endoscopic surgery, stereotactic surgery, and other minimally invasive procedures, the use of an IGS system allows the surgeon to achieve more precise movement and positioning of surgical instruments than could be achieved without its use. As a result, an IGS system can be particularly useful during the performance of various procedures where direct visualization of the surgical site is not possible (e.g., within the cardiovascular system), as well as various procedures where limited visualization is possible through the use of an endoscope or other device.

[0003] Although several systems and methods have been made and used in connection with IGS, it is believed that no one before the inventors has made and used the invention as recited in the appended claims. [Brief description of the drawings]

[0004] The following drawings and detailed description are merely illustrative and are not intended to limit the scope of the invention as contemplated by the inventors. [Figure 1] 1 illustrates a schematic diagram of an exemplary image-guided surgical navigation system. [Diagram 2] 2 illustrates a schematic diagram of an exemplary data transfer system including the image-guided surgical navigation system of FIG. 1; [Diagram 3] 3 illustrates a schematic diagram of an exemplary transfer module of the data transfer system of FIG. 2; [Figure 4] 3 illustrates a set of high-level steps that may be performed by the data transfer system of FIG. 2 to securely transfer data. [Diagram 5] 4 illustrates a set of steps that may be performed by the transfer module of FIG. 3 to update a configuration. [Figure 6]4 illustrates a set of steps that may be performed by a suitably configured user device to access and retrieve data from the transfer module of FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] The inventors have devised the novel techniques disclosed herein as applied, for illustrative purposes, in the context of image-guided surgery. Although the disclosed use of our techniques fulfills a long felt but unmet need in the art of image-guided surgery, our techniques are not limited to being performed in the exact manner described herein, and can be performed in other ways by those of skill in the art in light of this disclosure without undue experimentation. Thus, the examples described herein should be understood to be merely illustrative and should not be treated as limiting.

[0006] It is further understood that any one or more of the teachings, expressions, variations, examples, etc. described herein can be combined with any one or more of the other teachings, expressions, variations, examples, etc. described herein. Thus, the teachings, expressions, variations, examples, etc. described below should not be considered in isolation from one another. In view of the teachings herein, various suitable ways in which the teachings herein can be combined will be readily apparent to those skilled in the art. Such modifications and variations are intended to be within the scope of the claims.

[0007] I. Exemplary Image-Guided Surgical Navigation System 1 illustrates an exemplary IGS navigation system (100) that enables the performance of procedures using image guidance. The IGS navigation system (100) may be used with a variety of medical instruments (102) and other devices. In addition to or in lieu of having the components and operability described herein, the IGS navigation system (100) may be configured and operable in accordance with at least some of the teachings of the following documents:No. 8,702,626, entitled "Guidewires for Performing Image Guided Procedures," issued April 22, 2014, the disclosure of which is incorporated herein by reference; U.S. Patent No. 8,320,711, entitled "Anatomical Modeling from a 3-D Image and a Surface Mapping," issued November 27, 2012, the disclosure of which is incorporated herein by reference; U.S. Patent No. 7,720,521, entitled "Methods and Devices for Performing Procedures within the Ear, Nose, Throat and Paranasal Sinuses," issued May 18, 2010, the disclosure of which is incorporated herein by reference; U.S. Patent Application Publication No. 2014 / 0364725, entitled "Systems and Methods for Performing Image Guided Procedures within the Ear, Nose, Throat and Paranasal Sinuses," issued May 18, 2010, the disclosure of which is incorporated herein by reference; Sinuses,” published December 11, 2014, the disclosure of which is incorporated herein by reference; U.S. Patent Application Publication No. 2016 / 0310042, entitled “System and Method to Map Structures of Nasal Cavity,” published October 27, 2016; and U.S. Patent Application Publication No. 2011 / 0060214, entitled “Systems and Methods for Performing Image Guided Procedures within the Ear, Nose, Throat and Paranasal Sinuses,” published March 10, 2011, the disclosure of which is incorporated herein by reference.

[0008] The IGS navigation system (100) of this embodiment includes a medical device (102) (e.g., a catheter) equipped with one or more position sensors (104), a field generator (106), and a processor (110). By way of example only, the medical device (102) may include a catheter sized and configured to fit within a cardiovascular anatomical structure and provide a therapeutic effect (e.g., ablation of the anatomical structure). By way of further example only, each position sensor (104) may include a wire coil or multiple wire coils configured to generate an electrical signal in response to the presence of an alternating electromagnetic field and / or in response to movement within a static magnetic field. In variations having two or more wire coils forming the position sensor (104), the two or more wire coils may be oriented along respective axes that are orthogonal to one another or have any other suitable relationship to one another.

[0009] The field generator (106) of this example is configured to generate an alternating magnetic field around at least a portion of the patient. By way of example only, the field generator (106) may be integrated into a pad positioned under the patient. Alternatively, the field generator (106) may take any other suitable form. A position sensor (104) in the medical instrument (102) may generate an electrical signal when a portion of the instrument (102) equipped with the position sensor (104) is positioned within or near the patient within the electromagnetic field generated by the field generator (106). The signal generated by the position sensor (104) may indicate the position of the position sensor (104) within the three-dimensional space of the electromagnetic field, and thus the position of the portion of the instrument (102) equipped with the position sensor (104) (e.g., the distal end of the instrument (102)) within the three-dimensional space of the electromagnetic field. If the position of the patient within the three-dimensional space of the electromagnetic field is known, then the position of the portion of the instrument (102) equipped with the position sensor (104) within the three-dimensional space of the patient's anatomy may be derived based on signals from the position sensor (104). Other techniques that may be used to generate real-time position data associated with the medical instrument (102) may include radio triangulation, acoustic tracking, optical tracking, inertial tracking, etc.

[0010] The processor (110) of this embodiment comprises a computer processor or other processing unit in communication with one or more memories. The processor (110) calibrates and operates the system (100) using software stored in the memory of the processor (110). The processor (110) is in communication with the position sensor (104) such that the processor (110) may receive and process position-indicating signals generated by the position sensor (104). The processor (110) may communicate with the position sensor (104) via wires, wirelessly, or in any suitable manner, as will be apparent to one of ordinary skill in the art in view of the teachings herein. The processor (110) also communicates with the field generator (106) such that the processor (110) is operable to selectively activate the field generator (106) to thereby generate an electromagnetic field. A set of motion controls (112) are also in communication with the processor (110). The motion controls (112) may include a keypad, a pointing device such as a mouse or trackball, and / or any other suitable type(s) of user input mechanism(s) as will be apparent to one of ordinary skill in the art given the teachings herein. A physician may use the motion controls (112) to interact with the processor (110) while performing a surgical procedure.

[0011] The display screen (108) is coupled to the processor (110) and is operable to render an image of the patient's anatomy. Such an image may be based on a set of pre-operatively acquired images (e.g., CT or MRI scans, 3D maps, etc.). The view of the patient's anatomy provided through the display screen (108) may also change dynamically based on signals from the position sensor (104). For example, as the medical instrument (102) moves within the patient, the corresponding position data from the position sensor (104) may cause the processor (110) to update the view of the patient's anatomy on the display screen (108) in real time to illustrate the area of ​​the patient's anatomy surrounding the portion of the medical instrument (102) that includes the position sensor (104).

[0012] Additionally, the processor (110) may drive the display screen (108) to overlay the current location of the medical instrument (102) onto the preoperatively acquired image of the patient's anatomy, such as by overlaying a lighted dot, crosshairs, a visual representation of the medical instrument (102), or some other form of visual representation. Such an overlaid visual representation may also move in real-time within the image of the patient's anatomy on the display screen (108) as the physician moves the medical instrument (102) within the patient, thereby providing the operator with real-time visual feedback on the location of the medical instrument (102) within the patient. Thus, the image provided through the display screen (108) may effectively provide a video that tracks the position of the medical instrument (102) within the patient, without necessarily having any optics (i.e., a camera) that view the portion of the medical instrument (102) that is within the patient. Nevertheless, in situations where the operator also uses an endoscope or other type of optics, the endoscopic / optical image may also be provided on the display screen (108). The images provided through the display screen (108) may ultimately help guide the operator in steering or otherwise manipulating the instruments during a procedure.

[0013] II. Exemplary Medical Image Transfer System Some forms of the IGS navigation system (100) may store various types of data during an IGS procedure, including information and analysis describing the IGS procedure, still images generated or captured during the IGS procedure, video sequences generated or captured during the IGS procedure, and other data. Such stored information may further include a record of all data collected during the entire IGS procedure, which may be referred to as a "complete case record." At least some of the data stored by the IGS navigation system (100) may subsequently be needed for a variety of reasons, such as when a patient wishes to retain images or videos associated with the procedure for future treatment, or when a physician wishes to review images, videos, or other information related to the procedure to formulate a diagnosis or subsequent treatment plan.

[0014] Some forms of the IGS navigation system (100) may have some limited ability to communicate data to other systems and devices, and some are not capable of wireless communication using technologies such as Bluetooth, Wi-Fi, NFC, RFID, cellular, or other similar technologies. Some forms of the IGS navigation system (100) (e.g., those that are not networked within a hospital) may also not be capable of wired communication. In some variations of the IGS navigation system (100) that are not capable of wired or wireless communication, it may be necessary to physically retrieve the data from the IGS navigation system (100), such as by printing a physical copy of the images or information, using the system's optical drive to generate an optical data disc, such as a CD-ROM or DVD-ROM, or duplicating the data from the IGS system to a physically connected storage device, such as a USB hard drive or USB flash drive. Such data transfer procedures may have various drawbacks and limitations. For example, producing printed paper and optical data discs can be very time-consuming and relatively expensive in terms of materials and resources. Reproducing the data on a physically connected storage device can also be time consuming depending on a variety of factors, and can also be relatively expensive if such storage devices must be purchased and made readily available to physicians and patients. Whether on paper, disk, or storage device, physical reproduction of data can also present a risk of losing or misplacing the physical reproduction, potentially exposing important and sensitive medical data to the public. Furthermore, these traditional data transfer procedures to printed paper, optical data disks, and physically connected storage devices may lack automatic encryption or other forms of substantial data protection.

[0015] Some forms of the IGS navigation system (100) may also represent a significant capital investment for a hospital or other medical practice. As a result, it may not be desirable to replace an existing IGS navigation system (100) with a new form of the IGS navigation system (100) that includes improved data communication capabilities. Instead, it may be desirable to provide features that further facilitate the transfer of data from an existing IGS navigation system (100) without requiring replacement of the existing IGS navigation system (100). In other words, it may be desirable to provide a retrofit for an existing IGS navigation system (100) to thereby provide the existing IGS navigation system (100) with improved data transfer capabilities. Examples of such retrofits are described in more detail below. Although the following examples are described in the context of retrofitting an existing IGS navigation system (100), the same improved data communication features may also be provided in a new IGS navigation system (100), such that the existing state of the IGS navigation system (100) is not required to actually practice the following examples.

[0016] FIG. 2 shows a schematic diagram of a data transfer system (101) configured to enable data, such as images, videos, and treatment information captured or generated by an IGS navigation system (100), to be wirelessly and securely accessed by a user, even when the IGS navigation system (100) does not have wireless communication capabilities or when the IGS navigation system (100) has wireless communication capabilities that are not suitable for secure wireless access to potentially sensitive and important patient data.

[0017] In the embodiment shown in FIG. 2, the IGS navigation system (100) is communicatively coupled to the transfer module (120) via a physical connection, such as a USB port, an Ethernet port, a serial port, a parallel port, or any other standard or proprietary physical connection that allows for the exchange of data between two or more devices. Through this connection, the IGS navigation system (100) is configured to export images, videos, and other data to a physically connected storage device. The transfer module (120), shown in more detail in FIG. 3, appears to the processor (110) as a physically connected storage device (e.g., as a USB connected flash drive or hard drive) and is configured to securely receive procedure data and images from the IGS navigation system (100) during the export of such data. The transfer module (120) is configured to securely store the received data and wirelessly provide some or all of the data to a requesting device that can authenticate and verify it.

[0018] The transfer server (122) is configured to allow an administrative user to maintain authorization and validation records of users and devices, and to maintain and provide software configurations and software updates to one or more transfer modules (120). The transfer server (122) may provide the configurations to the transfer modules (120) wirelessly via the same wireless communication devices and networks used to provide images and data to users, over a network using a fixed physical connection such as USB or Ethernet, or through a manual process such as copying the configurations from the transfer server (122) to a physical storage device such as a USB flash drive that can be temporarily connected to the IGS navigation system (100).

[0019] The transfer module (120) of this embodiment is wirelessly coupled to devices such as a trusted user device (126) and a new user device (124). By way of example only, the user devices (124, 126) may include smartphones, tablets, laptops, or other devices having software configurations and hardware capabilities that allow for secure exchange of data with the transfer module (120). The user devices (124, 126) may also include mobile or fixed location workstations within a hospital. Other suitable forms that the user devices (124, 126) may take will be apparent to those skilled in the art in light of the teachings herein. The trusted user device (126) of this embodiment is a device recognized by the transfer module (120) that has already been configured and authenticated for secure access to some or all of the data received from the IGS navigation system (100). The new user device (124) in this embodiment is a device that is not recognized by the forwarding module (120) because it is either an unauthenticated device or a device that was previously authenticated but whose authentication has expired or been changed in some way.

[0020] The new user device (124) also communicates wirelessly with an authentication server (128), which may be the same or a separate device as the transfer server (122), and is configured to determine whether the new user device (124) should be allowed access to one or more images or other data on the transfer module (120) based on information from one or more of the new user device (124), the transfer server (122), or the transfer module (120). In some implementations, the trusted user device (126) and the new user device (124) communicate with the transfer module (120) using basic features of their operating systems or standard software, while in other implementations, communication with the transfer module (120) is performed using dedicated software applications installed and executed on the devices (124, 126) for the purpose of receiving data from the transfer module (120).

[0021] Regardless of whether a particular device (124, 126) is trusted or untrusted, FIG. 2 also illustrates that the transfer module (120) may communicate directly with the trusted user device (126) (or, in other cases, the new user device (124)) without a typical network connection via wireless communication such as Bluetooth or Wi-Fi Direct. Such a connection may allow a physician or patient to transfer data from the transfer module (120) immediately or shortly after a procedure while still in close proximity to the IGS navigation system (100) and the connected transfer module (120). The transfer module (120) may also communicate with devices such as the new user device (124) (or, in other cases, the trusted user device (126)) via a wireless connection to a wireless local area network or wide area network such as the network (130). Such a connection may enable a physician or patient to transfer data from the transfer module (120) while located in an area where they can connect to the network (130), in the case of a local area network, or, in implementations where the network (130) is a wide area network, from their own home, another physician's office, or any other location with access to the wide area network (130).

[0022] In some implementations, providing the network (130) in the form of a local area network may advantageously provide an increased level of data security by preventing general access over a wide area network, and may allow the transfer modules (120) to be configured to only communicate over a dedicated local area network with a unique or hidden network name and password provided only to a small set of users who need to access the IGS navigation system (100) data. The unique dedicated network may be shared across one or more transfer modules (120), or may be uniquely designated for each transfer module (120) based on further partitioning the network (130).

[0023] In addition to the use of wireless local area networks and wide area networks (130), the data transfers described herein may also be performed over cellular connections (e.g., 4G, 5G, etc.). Furthermore, such cellular and other wireless connections may be used to communicate data to a remote cloud storage system from which the user devices (124, 126), servers, and / or other devices on the hospital or other facility site may later access the data. In other words, while the arrangement shown in FIG. 2 provides a direct communication path between the user devices (124) and the transfer module (120) over the network (130), some other arrangements may provide a cloud storage system as an intermediary between the transfer module (120) and the user devices (124), with the transfer module (120) in communication with the cloud storage system over a network (e.g., the network (130), a cellular data connection, etc.) and with the user devices (124) in communication with the cloud storage system over a network (e.g., the network (130), a cellular data connection, etc.). The cloud storage system may be located remotely from the hospital or other facility where the IGS navigation system (100) and transfer module (120) are located. As described herein, data transmitted from the transfer module (120) to the cloud storage system may be encrypted, and such encryption may be maintained as the data is transferred from the cloud storage system to the user device (124), with the user device (124) decrypting the data. This same arrangement may be used to provide data from the cloud storage system to any user device (124, 126) (e.g., mobile devices or hospital workstations, etc.), servers on site at the hospital or other facility, and / or other devices.

[0024] FIG. 3 shows a schematic diagram of exemplary components of the transfer module (120). As can be seen, the transfer module comprises a processor (132) capable of receiving and transmitting data, processing data, and executing software. The processor (132) is in communication with a memory (134) capable of storing and accessing data used by the processor (132). The transfer module (120) also comprises a storage device (136) for storing data received from the IGS navigation system (100), for storing configuration related to user access and validation, device access and validation, performance and execution of various tasks, and maintenance of the transfer module (120), and other data. By way of example only, the storage device (136) may comprise a flash memory device, such as a USB flash memory drive, an SD card, or any other suitable type of storage device. The transfer module (120) also includes a communication device (138), which may include one or more of a wireless transceiver for Bluetooth, Wi-Fi, RFID, NFC, cellular data, and / or other suitable wireless communication technologies. The transfer module (120) further includes an IGS system interface (140), which may include a USB connection, an Ethernet connection, or other physical or mechanical connection that allows the transfer module (120) to be coupled with the IGS navigation system (100) for data transfer.

[0025] By way of example only, the transfer module (120) may comprise a single board computer ("single board computer, SBC") such as a RASPBERRY PI® device by the Raspberry Pi Foundation of Cambridge, United Kingdom, having capacity such as Wi-Fi and partitions for USB mass storage devices and / or SD card mass storage devices, configured for secure HTTP ("HTTPS") communications with secure socket layer ("SSL") with self-signed certificates, server-side execution of all programming and scripts using secure scripting frameworks such as Node JS and Express Server, scripts to manage wireless connections, device authentication, file encryption, audit logs, and file cleanup, and static network configuration. In some versions in which the transfer module (120) comprises a RASPBERRY PI® device, the transfer module (120) may couple to the IGS navigation system (100) via a USB coupling and wirelessly transfer data from the IGS navigation system (100) via Wi-Fi. In some such variations, the transfer module (120) couples to a USB port on the IGS navigation system (100) that is otherwise used to transfer images and other data from the IGS navigation system (100) to a flash drive or other USB storage device. Other suitable devices and configurations that can be used to provide the transfer module (120) will be apparent to those of ordinary skill in the art in view of the teachings herein.

[0026] III. Exemplary Medical Image Transfer Methods 4 illustrates an exemplary set of high-level steps that the data transfer system (101) may perform to provide improved data transfer capabilities to users of the IGS navigation system (100). Initially, the transfer module (120) may be installed (block 200) on the IGS navigation system (100) and configured for use. In some implementations, the transfer module (120) may be manually configured by an administrator prior to installation, while in other implementations the transfer module (120) may be automatically configured by transferring a set of configuration data to the transfer module (120) via the IGS system interface (140) or another interface. Upon initial startup or at regular intervals, the transfer module (120) may check the configuration information and implement changes when detected. The configuration provided to the transfer module (120) may include Wi-Fi configuration (e.g., SSID, password), network configuration (e.g., default static IP address and port), file system configuration (e.g., space allocated for data from the IGS navigation system (100), data refresh intervals, data retention policies), encryption and security settings (e.g., HTTPS configuration, SSL certificate, SHA / RSA keys), local audit log parameters (e.g., types of logged activity, user audit setup, log size, and retention), and other settings.

[0027] As medical procedure data is generated (block 202) during a medical procedure performed with the assistance of the IGS navigation system (100), images, videos, and / or other information may be generated and stored on the IGS navigation system (100). With the transfer module (120) installed (block 200) and configured for use, at least some of the data generated during the medical procedure (block 202) should be received (block 204) by the transfer module (120) by being sent from the IGS navigation system (100), pushed at configurable intervals, pulled on demand, or both. The data received (block 204) by the transfer module (120), including both the data itself as well as the file name and any associated metadata, is encrypted (block 206) and stored on the storage device (136) of the transfer module (120) so that it is not easily accessible by those with physical access to the transfer module (120).

[0028] A user may request some or all of the stored data from the transfer module (120) (block 208) by using an appropriately configured user device, such as a new user device (124) or a trusted user device (126). The requesting of data (block 208) may be performed through a web browser or other functionality built into the operating system of the requesting user device, or through a software application provided by an administrator of the transfer module (120) and installed on the user device. The request (block 208) may be performed on a schedule (e.g., automatically at the start or end of a day), or on demand (e.g., immediately after the completion of a medical procedure), or at any other time or schedule desired. As another merely illustrative example, the request (block 208) may be performed on an ad-hoc basis during a medical procedure. For example, the transfer module (120) may provide for intra-procedural data transfer of a surgeon to receive clinical feedback from peers, mentors, etc. during a medical procedure. As yet another merely illustrative example, the request (208) may be performed during or after a medical procedure to provide data to a hospital electronic medical record (EMR) for inclusion within the patient's procedure notes and / or medical record. Other scenarios in which it may be desirable to provide a request (block 208) for medical procedure data will be apparent to those of ordinary skill in the art in view of the teachings herein.

[0029] When the transfer module (120) receives a request for medical procedure data (block 208), the request is validated (block 210) before any information is provided. Validation (block 210) may include one or more of user validation (e.g., authenticating the user based on a username and password, biometrics, or other similar methods), user device (124, 126) validation (e.g., verifying that the user device (124, 126) from which the request originates has a security device such as a token or certificate, MAC address or unique device address validation, or other similar methods), and may also include administrative or legal validation steps. This may include, for example, providing a request to a third party that is manually reviewed and approved before the data is provided, determining whether the requester has a valid reason to request particular data (e.g., based on being listed as a care provider for the relevant patient or based on being used in a particular position or role that requires the data), or ensuring that the requester has agreed to keep the data confidential (e.g., capturing a signature, password, biometric identifier, or image of the user of the requesting device and associating it with acceptance of a set of legal terms and conditions to receive the requested data).

[0030] As described herein, biometric identification may include the creation of a unique key based on a particular user's face, fingerprint, voice, or other captureable biometric input. Such a unique key may be used to authenticate access to the transfer module (120), user devices (124, 126), or other devices of the data transfer system (101), and may also be used in whole or in part as part of an encryption / decryption key for data stored or accessed on any such device. Such examples may include storing user credentials for the user device (126) in encrypted form, where the biometric data provides a decryption key, enabling the user device (126) to communicate with the transfer module (120), or the user device (126) receiving encrypted procedure data (e.g., pre- or post-operative images) from the transfer module (120) and decrypting the data for viewing using a decryption key based in whole or in part on biometric data associated with a particular patient authorized to have access to such data, or a particular physician authorized to have access to such data, or other variations of such embodiments.

[0031] Once the request is verified as valid (block 210), the transfer module (120) may provide the requested data over the configured wireless connection (block 212). Providing the data (block 212) may include providing some or all of the data during one or more exchanges. For example, the transfer module (120) may first provide a list of file names, patient names, physician names, or procedure names associated with data currently stored on the transfer module (120) (block 212). Based on an additional request from the user for one or more of the listed files, the transfer module (120) may provide the requested file itself. The data provided wirelessly (block 212), whether file names or actual files, is encrypted in transit and only decrypted after receipt by authorized devices (124, 126). Providing the requested data (block 212) may be performed in a variety of ways. For example, in some variations, the data may be provided by a web server running on the transfer module (120) with anonymous authentication via HTTP. Such web servers may be customized only to disable or prohibit functions necessary to transmit files to requesting users, such as common web server functions such as POST, PUT, and DELETE, and to provide other modifications to improve security, to remove features that may expose unnecessary, unintended functionality, and to prevent cross-side scripting and other web server vulnerability attacks.

[0032] Other implementations may include a web server running on the transfer module (120) that serves the requested data using HTTPS with a self-signed certificate and local SSL. This may be paired with customized scripts or software installed on the user devices (124, 126) to automatically honor or ignore warnings related to the SSL certificate of the transfer module (120). Such implementations may also use customized web servers that provide only a minimal set of functions to allow data to be provided to the user devices (124, 126) and may include additional security features to prevent automatic generation and updating of local SSL certificates to avoid cross-side script and other web server attacks, as well as the need for manual creation and updating of certificates over time.

[0033] Other implementations may be configured to email the data to users instead of, or in addition to, providing the data over HTTP or HTTPS. The emails may be generated based on templates for each individual or for groups of users so that the emails provided to users can be customized to their preferences.

[0034] The data transfer system (101) may also be configured to periodically perform a data maintenance (block 214) task. This may include having the IGS navigation system (100) store or discard data based on a set of retention rules, having the transfer module (120) store or discard data based on a set of retention rules, and / or having the user devices (124, 126) store or discard data based on a set of retention rules. As an example, the transfer module (120) may be variably configured to apply file retention policies to storage on the storage device (136), which may include limiting the total amount of data stored at any one time, limiting the number of patients or procedures for which data is stored at any one time, limiting the number of days a set of data may be stored before a particular set is automatically deleted, and other data retention rules. Such configuration may be statically configured by an administrator or manufacturer of the transfer module (120) or may be configured from time to time using a configuration change file, as described below.

[0035] FIG. 5 illustrates an exemplary set of steps that may be performed by the transfer module (120) during configuration. These steps may be performed by an application or script running on the transfer module (120) and may periodically scan the configuration file placed or transferred on the transfer module (120). When a configuration change is received (block 220), the transfer module (120) will determine the contents of the configuration change. This may include identifying the new Wi-Fi configuration such as SSID and password, new encryption / decryption key, key change flag as key version number, and other similar configuration changes, as well as the current encryption / decryption key that may be used to verify the configuration change before it is implemented. The transfer module (120) may verify that the current encryption key provided is valid by decrypting the file as a test, and if determined to be valid, may cause the configuration to be changed. If the key is invalid, an error may be returned by updating the configuration file to reflect the occurrence of the error to subsequent viewers of the configuration file, or an error notification may be sent over the air.

[0036] If the configuration change is valid but does not contain a positive key change flag (block 222), the transfer module (120) may update its configuration according to the provided configuration file or data (block 224), but will not make any encryption-related changes. If the configuration change contains a positive key change flag (block 222), all files and data on the transfer module (120) will be decrypted using the current key from the configuration change (block 228) and then encrypted using the new key from the configuration change (block 230). After successful decryption (block 228) and encryption (block 230), the local configuration of the transfer module (120) will be updated based on the configuration change (block 232), and the new key from the configuration change will be stored on the transfer module (120) as the current key. The transfer module (120) may also update the configuration status (block 234), which may include returning a notification to the transfer server (122), generating a successful configuration change flag or file locally, or providing a perceptible notification via the transfer module (120) itself. Such a perceptible notification may be provided in the form of a flashing light or other visual indicator, in the form of an audible confirmation, and / or in any other suitable form. Operating in the manner shown in FIG. 5, configuration changes to the transfer module (120) may be securely updated by a system administrator who has physical access to the transfer module (120) or access to the network (130) to which the transfer module (120) is connected.

[0037] FIG. 6 illustrates a set of steps that may be performed by a user device, such as the new user device (124), to securely provide access to medical procedure data to a requesting user. In some implementations, the steps of FIG. 6 may be performed by a software application, such as an Android, iOS, or Windows mobile application, which may be a native application or a hybrid application, or in some implementations, a website accessible via a web browser. Upon first accessing the software, the transfer module (120) authenticates the user based on a username and password, a biometric code, or other similar authentication measures (block 250). User authentication may be performed by the transfer module (120) in conjunction with one or more of the transfer server (122) and the validation server (128), which may be configured to store a database that stores some or all of the authentication information necessary to verify the username and password or other authentication code.

[0038] Once the user has been authenticated (block 250), the user device (124) may receive a data request from a user of the user device (124) via a user interface, such as a touch screen, keyboard, or other interface (block 252). The data request may be, for example, a request for data associated with a particular IGS navigation system (100), or for a particular patient, physician, or procedure associated with one or more IGS navigation systems (100). Before acting on the request, the user device (124) determines an encryption key and MAC address based on locally available information, communications with the transfer module (120), or both, and uses that information to validate the user device (124) for communication with the transfer module (120) (block 254). Validating the user device (124) (block 254) may be accomplished, for example, by querying a local database bundled with the user device (124) software and updated from time to time to determine whether a record exists in a mapping table that associates a device-unique MAC address with an encryption key. This database may consist of fields such as the user device 124 MAC address or other unique identifier, the encryption and decryption file names that may be used to verify the validity of the encryption key, the transport module 120 MAC address or other unique identifier, and the date and time of record creation or entry into the database.

[0039] For example, if the key cannot be validated (block 254) because there is no record uniquely associating the user device 124 with the key, the user device 124 will prompt the user to enter a new encryption key (block 256). Similarly, if there is a record associating the user device 124 with the key, but the key version from the local database does not match the current key version based on information from the transport server 122 or the validation server 128, the user device 124 will prompt the user to enter a new encryption key (block 256).

[0040] If the keys can be verified as valid (block 254) and the key versions match (block 258) or the user is prompted for a new key (block 256), the user device 124 may then display an image selection screen showing a set of file names associated with the data stored on the transfer module 120 (block 260). This may be accomplished, for example, by receiving the set of file names in encrypted form associated with the data request from the transfer module 120 (block 252). The set of file names may be stored on the user device 124 in encrypted form, with a decrypted version being created and stored only temporarily for the purpose of verifying that the encryption key is valid, and after all validation steps have been completed, immediately prior to providing the decrypted image or other data to the requester (e.g., using an email template, within a secure application or browser session, by email to a secure account, or otherwise).

[0041] The user device 124 may prompt the user to confirm one or more of the file names to verify that the correct data was identified on the transfer module 120 and that the user is authorized to access it, and may verify that one or more of the file names, thumbnails, or other information are valid by using a key to decrypt the data and examining the results (block 262). This may include, for example, selecting an encrypted file name present in a record in the local database, decrypting the file name with the encryption key, and comparing the results to the decrypted file name also stored in the local database. If the user device 124 is unable to verify that the file name was decrypted correctly (block 262), the user may be prompted for a new key (block 256).

[0042] If the user device (124) is able to verify that the filename is valid (block 262), then the user device (124) would determine whether the encryption key used throughout the steps of Figure 6 is an initially valid key, such as a new key used for the first time, or an old key whose version still matches the current key version, or whether the key has been updated during the process (block 264) by prompting the user to enter a new key (block 256). If the key is initially valid and does not need to be updated (block 264), the user device (124) would retrieve the requested images or data from the transfer module, decrypt them, and display or otherwise provide the requested data to the user (block 268). If the key was updated during the process by prompting the user to enter a new key (block 256), the user device 124 should notify the user (block 266) that old files and data stored on the user device 124 that were associated with the old encryption key and are no longer valid (e.g., due to version mismatch, failure to decrypt filename, or other reasons) have been deleted and must be re-downloaded if continued access is desired. This prevents the user device 124 from collecting different sets of files and data over time, each of which requires a different encryption key to access. Once the user has been notified of cleanup and other maintenance associated with the updated key (block 264) (block 266), the user device 124 may then provide the requested files and data to the user (block 268).

[0043] Providing the requested images or data to the user (block 268) may include providing the user with a preview of the images, videos, and other data associated with the request available on the transfer module (120) in thumbnail or preview form. In some implementations, this may include using HTTP or HTTPS calls to a web server of the transfer module (120) to obtain the full path of each associated image, video, or other data, and using those paths to render and display a preview web page within a browser window, native application, or hybrid application. Providing the requested images or data (block 268) may also include receiving input via a user interface of the user device (124, 126) indicating one or more of the preview images or other data, and using HTTP or HTTPS calls to a web server of the transfer module (120) to download the indicated data directly to the user device (124, 126), where it may be stored in encrypted form and decrypted upon request when viewed by the user of the user device (124, 126) or emailed to a secure email account associated with the authenticated user.

[0044] In either case, after the user device (124) provides the data to the user (block 268), a local database may be created, inserted, or otherwise updated (block 270) with records associated with the unique hardware identifier of the user device (124) to account for the fully validated encryption and decryption keys, their versions, and other validation information stored within the local database. Once the local database is updated (block 270), it may be periodically synchronized with a similar database available on the transport server (122), validation server (128), or another remote store to reduce the number of validation steps that may be performed during the process of FIG. 6 and provide more streamlined access for users of the user devices (124, 126).

[0045] IV. Exemplary Combinations The following examples relate to various non-exhaustive methods in which the teachings herein may be combined or applied. It should be understood that the following examples are not intended to limit the scope of any claims that may be presented at any time in this application or in a later application of this application. No disclaimer is intended. The following examples are provided for illustrative purposes only. It is contemplated that the various teachings herein may be configured and applied in many other ways. It is also contemplated that certain features mentioned in the following examples may be omitted in some variations. Thus, none of the aspects or features mentioned below should be considered as critical unless expressly indicated to be so at a later date by the inventor or the inventor's successor in interest. If a claim including additional features other than those mentioned below is presented in this application or in a later application related to this application, those additional features should not be assumed to have been added for any reason related to patentability. EXAMPLES

[0046] 1. A data transfer system comprising: (a) a transfer module having a storage device, a wireless communication device, and a data interface, the data interface being configured to couple to an image-guided surgical navigation system and receive data from the image-guided surgical navigation system, the wireless communication device being configured to connect to a wireless network; (b) a transfer server configured to provide security and authentication services associated with accessing the transfer module; and (c) a user device having a display and a user interface, the user device communicating with the transfer module over the wireless network, wherein the transfer module is configured to: (i) receive a set of medical procedure data from the image-guided surgical navigation system; (ii) encrypt the set of medical procedure data using a current key as a set of encrypted medical procedure data, store the encrypted medical procedure data on the storage device, and delete the set of medical procedure data; (iii) receive a medical procedure data request from the user device; and (v) provide the set of encrypted medical procedure data to the user device. EXAMPLES

[0047] The system of Example 1, wherein the user device is configured to: (i) store a device key and a device key version; (ii) authenticate a user of the user device; (iii) verify whether the user device is legitimate based on the device key and a current key; (iv) when the user device is not verified to be legitimate, prompt the user for a new key and set it as the device key, and then delete any information associated with the previous device key on the user device; and (v) when the user device is verified to be legitimate, receive a set of encrypted treatment data and decrypt the set of encrypted treatment data using the device key. EXAMPLES

[0048] The system of Example 2, wherein the user device is further configured to (i) receive a set of authentication data from the user, (ii) provide the authentication data to the forwarding server, and (iii) authenticate the user based on an authentication response from the forwarding server. EXAMPLES

[0049] The system of Example 2 or 3, wherein the user device is further configured to: (i) store a local validation database including a unique hardware identifier, a file description, an encrypted file description, and a key version, where the file description and the encrypted file description both describe the same file and the encrypted file description was created from the file description using the device key; (ii) receive a module identifier and a module key version from the transfer module; and (iii) validate that the user device is valid when the local validation database contains a record that the key version in the local validation database matches the module key version and that the module identifier in the local validation database matches the unique hardware identifier. EXAMPLES

[0050] The system of any one of Examples 2 to 4, wherein the user device is further configured to: (i) receive a module key version from the transfer module; and (ii) verify that the user device is authentic when the module key version matches the device key version. EXAMPLES

[0051] The system of any one of Examples 2 to 5, wherein the user device is further configured to: (i) store a local validation database including a file description and an encrypted file description, both of which describe a file stored on the transfer module, and the encrypted file description is created from the file description using a device key; (ii) request a file portion associated with the encrypted file description from the transfer module; (iii) decrypt the file portion using the device key to create a decrypted file portion; and (iv) verify that the user device is valid if the decrypted file portion matches the file description. EXAMPLES

[0052] The system of any one of Examples 2 to 6, wherein the user device is further configured to: (i) select a set of encrypted file names from the set of encrypted medical procedure data; (ii) if the user is authenticated and the user device is confirmed to be valid, decrypt the set of file names to create a set of file names and display the set of file names via the display; and (iii) receive a selection from the user identifying one or more of the set of file names. EXAMPLES

[0053] The system of Example 7, wherein the user device is further configured to: (i) decrypt a set of files from the set of encrypted medical procedure data based on the selection to create a set of decrypted files and display the set of decrypted files via the display; and (ii) delete the set of decrypted files when the set of decrypted files is no longer displayed via the display. EXAMPLES

[0054] The system of Example 7 or 8, wherein the user device is further configured to: (i) decrypt a set of files from the set of encrypted treatment data based on the selection to create a set of decrypted files and send the set of decrypted files to a secure destination associated with the user; and (ii) delete the set of decrypted files after sending the set of decrypted files. EXAMPLES

[0055] The system of any one of Examples 1 to 9, wherein the wireless communication device is selected from the group consisting of a Wi-Fi transceiver, a Bluetooth transceiver, and a cellular data transceiver, the data interface is selected from the group consisting of a USB connection and an Ethernet connection, and the transfer module is a single-board computer. EXAMPLES

[0056] The system of any one of Examples 1 to 10, wherein the transfer module is further configured to: (i) receive a configuration data set, the configuration data set including a previous key, a new key, and a new key version; (ii) verify that the current key is different from the new key; (iii) decrypt the set of encrypted medical procedure data using the previous key to create a second set of encrypted medical procedure data and delete the set of encrypted medical procedure data; (iv) encrypt the second set of medical procedure data using the new key to create a second set of encrypted medical procedure data and delete the second set of encrypted medical procedure data; and (v) update a local configuration to make the device key version equal to the new key version and the current key equal to the new key. EXAMPLES

[0057] The system of any one of Examples 1 to 11, wherein the forwarding server is configured to: (i) store a set of email templates, each email template associated with a user, and each email template configured to format a set of medical procedure data for transmission to the user; (ii) receive a template request from a user device, the template request including an identifier of the user and acceptance conditions; (iii) provide to the user device an email template from the set of email templates associated with the user; and (iv) store the acceptance conditions, the user acceptance conditions including a legal agreement and instructions for the user's acceptance of the legal agreement. EXAMPLES

[0058] A system as described in any one of Examples 1 to 12, wherein the forwarding module is configured to (i) provide a web server with which a user device can communicate over the wireless network, and (ii) connect to the wireless network using a static address, and the wireless network consists of peers that are either forwarding modules, such as the forwarding module, or user devices, such as the user device. EXAMPLES

[0059] The system of Example 13, wherein the forwarding module is further configured to: (i) restrict functionality of the web server to prevent use of a set of commands, the set of commands including POST, PUT, and DELETE; (ii) generate a self-signed Secure Sockets Layer certificate, the self-signed Secure Sockets Layer certificate having a duration; and (iii) generate a new self-signed Secure Sockets Layer certificate when the duration has elapsed. EXAMPLES

[0060] 11. A method for transferring data from an image-guided surgical navigation system, the method comprising: (a) installing a transfer module on the image-guided surgical navigation system, the transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple to and receive data from the image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network; (b) receiving a set of medical procedure data from the image-guided surgical navigation system with the transfer module; (c) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; and (d) providing the set of encrypted medical procedure data to a user device, the user device comprising a display and a user interface, the user device communicating with the transfer module through the wireless network. EXAMPLES

[0061] The method of example 15, further comprising: (a) storing the device key and the device key version; (b) authenticating a user of the user device; (c) verifying whether the user device is valid based on the device key and the current key; (d) when the user device is not verified as valid, prompting the user for a new key and setting it as the device key, and then deleting any information associated with the previous device key on the user device; and (e) when the user device is verified as valid, receiving a set of encrypted medical procedure data and decrypting the set of encrypted procedure data. EXAMPLES

[0062] The method of claim 16, further comprising: (a) receiving a set of authentication data from a user; (b) providing the authentication data to a forwarding server; (c) authenticating the user based on an authentication response from the forwarding server; (d) storing a local validation database on the user device, the local validation database including a unique hardware identifier, a file description, an encrypted file description, and a key version, where the file description and the encrypted file description both describe the same file, and the encrypted file description was created from the file description using a device key; (e) receiving a module identifier and a module key version from the forwarding module; and (f) validating that the user device is valid when the local validation database contains a record that the key version in the local validation database matches the module key version and that the module identifier in the local validation database matched the unique hardware identifier. EXAMPLES

[0063] The method of any one of Examples 15 to 17, further comprising: (a) receiving, at the transfer module, a configuration data set, the configuration data set including a previous key, a new key, and a new key version; (b) verifying that the current key is different from the new key; (c) decrypting the set of encrypted medical procedure data using the previous key to create a second set of encrypted medical procedure data and deleting the set of encrypted medical procedure data; (d) encrypting the second set of medical procedure data using the new key to create a second set of encrypted medical procedure data and deleting the second set of medical procedure data; and (e) updating a local configuration of the transfer module to make the device key version equal to the new key version and the current key equal to the new key. EXAMPLES

[0064] The method of any one of Examples 15 to 18, further comprising the steps of: (a) providing a web server on the transfer module with which the user device can communicate over the wireless network; (b) connecting the transfer module to the wireless network using a static address; (c) restricting the functionality of the web server to prevent use of a set of commands, the set of commands including POST, PUT, and DELETE; (d) generating a self-signed Secure Sockets Layer certificate, the self-signed Secure Sockets Layer certificate having a duration; and (e) generating a new self-signed Secure Sockets Layer certificate when the duration has elapsed. EXAMPLES

[0065] 1. A data transfer system comprising: (a) a transfer module having a storage device, a wireless communication device, and a data interface, the data interface being configured to couple to an image-guided surgical navigation system and receive data from the image-guided surgical navigation system, the wireless communication device being configured to connect to a wireless network via Wi-Fi or a cellular signal; (b) a cloud storage system, the cloud storage system being in communication with the transfer module over the wireless network via Wi-Fi or a cellular signal; and (c) a user device having a display and a user interface, the transfer module being configured to: (i) receive a set of medical procedure data from the image-guided surgical navigation system; and (ii) encrypting the set of medical procedure data as a set of encrypted medical procedure data using the current key, storing the encrypted medical procedure data on a storage device, and deleting the set of medical procedure data; and (iii) providing the set of encrypted medical procedure data to a cloud storage system, wherein the cloud storage system is configured to (i) receive a medical procedure data request from a user device, and (ii) provide the set of encrypted medical procedure data to the user device, and the user device is configured to (i) receive the encrypted medical procedure data from the cloud storage system, (ii) decrypt the medical procedure data, and (ii) display at least some of the medical procedure data to an end user. EXAMPLES

[0066] A data transfer system comprising: (a) a transfer module having a storage device, a wireless communication device, and a data interface, the data interface being configured to couple to and receive data from an image-guided surgical navigation system, the wireless communication device being configured to connect to a wireless network; and (b) a user device having a display and a user interface, the user device communicating with the transfer module over the wireless network. The user device and the transfer module are configured to: (i) receive a set of medical procedure data from the image-guided surgical navigation system; (ii) encrypt the set of medical procedure data using a current key as a set of encrypted medical procedure data, store the encrypted medical procedure data on the storage device, and delete the set of medical procedure data; (iii) receive a medical procedure data request from the user device; and (iv) provide the set of encrypted medical procedure data to the user device. and (c) receiving from the transfer module a file portion associated with the module identifier, the module key version, and the encrypted file description, the file portion being decrypted using the current key to create a decrypted file portion; and validating the user device as authentic when: (A) the key version in the local validation database matches the module key version, and the module identifier in the local validation database matches the unique hardware identifier; (B) the module key version matches the current key version; and (C) the encrypted file portion matches the file description.(iv) when the user device is not validated, prompting a user for a new key and setting it as the current key, then deleting any information on the user device associated with the previous device key; and (v) when the user device is not validated, receiving a set of encrypted medical procedure data and decrypting the set of encrypted medical procedure data using the current key.

[0067] V.Other It should be understood that any of the embodiments described herein may include various other features in addition to or in place of those described above. By way of example only, any of the embodiments described herein may also include one or more of the various features disclosed in any of the various references incorporated herein by reference.

[0068] It should be understood that any one or more of the teachings, expressions, embodiments, examples, etc. described herein can be combined with any one or more of the other teachings, expressions, embodiments, examples, etc. described herein. Thus, the above teachings, expressions, embodiments, examples, etc. should not be considered in isolation from one another. In view of the teachings herein, various suitable ways in which the teachings herein can be combined will be readily apparent to those skilled in the art. Such modifications and variations are intended to be within the scope of the claims.

[0069] Any patent, publication, or other disclosure that is referred to as being incorporated herein by reference should be understood to be incorporated herein, in whole or in part, only to the extent that the incorporated content does not contradict the current definitions, opinions, or other disclosures described herein. As such, and to the extent necessary, the disclosures explicitly described herein shall take precedence over any conflicting statements incorporated herein by reference. Any content, or portions thereof, that contradicts the current definitions, opinions, or other disclosures described herein shall be incorporated herein by reference, but only to the extent that no conflict arises between the reference content and the current disclosures.

[0070] Although various variations of the present invention have been shown and described, further applications of the methods and systems described herein can be realized by those skilled in the art through appropriate modifications without departing from the scope of the present invention. Although some of such possible modifications have been described, other modifications will be apparent to those skilled in the art. For example, the above-mentioned embodiments, variations, geometries, materials, dimensions, ratios, steps, etc. are exemplary and not required. Therefore, the scope of the present invention should be considered in terms of the following claims and should not be understood as being limited to the details of structure and operation shown and described in this specification and drawings.

[0071] [Embodiment] (1) A data transfer system comprising: (a) a transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple to and receive data from an image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network; (b) a transport server configured to provide security and authentication services associated with access to the transport module; and (c) a user device having a display and a user interface, the user device in communication with the transfer module over the wireless network; The transfer module: (i) receiving a set of medical procedure data from the image-guided surgical navigation system; (ii) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; (iii) receiving a medical procedure data request from the user device; and (v) providing the set of encrypted medical procedure data to the user device. (2) the user device: (i) storing a device key and a device key version; (ii) authenticating a user of the user device; and (iii) validating the user device based on the device key and the current key; and (iv) when the user device is not validated, prompting the user for a new key, setting it as the device key, and then deleting any information on the user device associated with the previous device key; (v) when the user device is confirmed to be authentic, receiving the set of encrypted treatment data and decrypting the set of encrypted treatment data using the device key. (3) the user device; (i) receiving a set of authentication data from the user; (ii) providing the authentication data to the forwarding server; and (iii) authenticating the user based on an authentication response from the transfer server. (4) the user device, (i) storing a local validation database including a unique hardware identifier, a file description, an encrypted file description, and a key version, wherein the file description and the encrypted file description both describe the same file, and the encrypted file description was created from the file description using the device key; (ii) receiving a module identifier and a module key version from the transport module; (iii) verifying that the user device is authentic when the local validation database contains a record in which a key version of the local validation database matches the module key version and a module identifier of the local validation database matches the unique hardware identifier. (5) The user device, (i) receiving a module key version from the transfer module; (ii) verifying that the user device is authentic when the module key version matches the device key version.

[0072] (6) The user device, (i) storing a local validation database including a file description and an encrypted file description, the file description and the encrypted file description both describing a file stored on the transfer module, the encrypted file description being created from the file description using the device key; (ii) requesting file portions associated with the encrypted file description from the transfer module; and (iii) decrypting the file portion using the device key to create a decrypted file portion; (iv) verifying that the user device is authentic if the decrypted file portion matches the file description. (7) The user device, (i) selecting a set of encrypted file names from said set of encrypted medical procedure data; (ii) if the user is authenticated and the user device is confirmed to be valid, decrypting the set of file names to create a set of file names and displaying the set of file names via the display unit; (iii) receiving a selection from the user identifying one or more of the set of file names. (8) The user device, (i) based on said selection, decrypting a set of files from said set of encrypted medical procedure data to create a set of decrypted files and displaying said set of decrypted files via said display; (ii) deleting the set of decrypted files when the set of decrypted files is no longer displayed via the display unit. (9) The user device, (i) based on the selection, decrypting a set of files from the set of encrypted treatment data to create a set of decrypted files, and transmitting the set of decrypted files to a secure destination associated with the user; 8. The data transfer system of claim 7, further configured to: (ii) delete the set of decrypted files after transmitting the set of decrypted files. (10) The data transfer system of embodiment 1, wherein the wireless communication device is selected from the group consisting of a Wi-Fi transceiver, a Bluetooth transceiver, and a cellular data transceiver, the data interface is selected from the group consisting of a USB connection and an Ethernet connection, and the transfer module is a single-board computer.

[0073] (11) The transfer module, (i) receiving a configuration data set, the configuration data set including a previous key, a new key, and a new key version; (ii) verifying that the current key is different from the new key; and (iii) decrypting the set of encrypted medical procedure data using the previous key to create a second set of medical procedure data and deleting the set of encrypted medical procedure data; and (iv) encrypting the second set of medical procedure data using the new key to create a second set of encrypted medical procedure data, and deleting the second set of medical procedure data; (v) updating a local configuration to make the device key version equal to the new key version and the current key equal to the new key. (12) The transfer server: (i) storing a set of email templates, each email template associated with a user, each email template configured to format the set of medical procedure data for transmission to that user; (ii) receiving a template request from the user device, the template request including an identifier of the user and terms acceptance; (iii) providing to the user device an email template from the set of email templates associated with the user; and (iv) storing the consent conditions; 2. The data transfer system of claim 1, wherein the user consent terms include a legal agreement and instructions for the user's consent to the legal agreement. (13) The transfer module, (i) providing a web server with which the user device can communicate over the wireless network; (ii) connecting to the wireless network using a static address; A data transfer system as described in embodiment 1, wherein the wireless network is made up of peers that are either transfer modules such as the transfer module or user devices such as the user device. (14) The transfer module, (i) restricting the functionality of the web server to prevent use of a set of commands, the set of commands including POST, PUT, and DELETE; (ii) generating a self-signed Secure Sockets Layer certificate, the self-signed Secure Sockets Layer certificate having a duration; (iii) generating a new self-signed Secure Sockets Layer certificate when the duration has elapsed. (15) A method for transferring data from an image-guided surgical navigation system, comprising: (a) installing a transfer module on the image-guided surgical navigation system, the transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple with and receive data from the image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network; (b) receiving, at the transfer module, a set of medical procedure data from the image-guided surgical navigation system; (c) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; (d) providing the set of encrypted medical procedure data to a user device, the user device having a display and a user interface, the user device being in communication with the transfer module over the wireless network.

[0074] (16) (a) storing a device key and a device key version; (b) authenticating a user of the user device; (c) validating the user device based on the device key and the current key; (d) when the user device is not validated, prompting the user for a new key and setting it as the device key, then deleting any information on the user device associated with the previous device key; 16. The method of claim 15, further comprising: (e) receiving the set of encrypted medical procedure data when the user device is verified as authentic, and decrypting the set of encrypted procedure data. (a) receiving a set of authentication data from the user; (b) providing the authentication data to a transfer server; (c) authenticating the user based on an authentication response from the transfer server; (d) storing a local validation database on the user device, the local validation database including a unique hardware identifier, a file description, an encrypted file description, and a key version, the file description and the encrypted file description both describing the same file, and the encrypted file description created from the file description using the device key; (e) receiving a module identifier and a module key version from the transport module; (f) validating that the user device is valid when the local validation database contains a record in which a key version in the local validation database matches the module key version and a module identifier in the local validation database matches the unique hardware identifier. (18) (a) receiving, at the transfer module, a configuration data set, the configuration data set including a previous key, a new key, and a new key version; (b) verifying that the current key is different from the new key; (c) decrypting the set of encrypted medical procedure data using the previous key to create a second set of medical procedure data and deleting the set of encrypted medical procedure data; (d) encrypting the second set of medical procedure data using the new key to create a second set of encrypted medical procedure data, and deleting the second set of medical procedure data; (e) updating a local configuration of the transport module to make the device key version equal to the new key version and the current key equal to the new key. (19) (a) providing a web server on the transfer module with which the user device can communicate over the wireless network; (b) connecting the transport module to the wireless network using a static address; (c) restricting the functionality of the web server to prevent use of a set of commands, the set of commands including POST, PUT, and DELETE; (d) generating a self-signed Secure Sockets Layer certificate, the self-signed Secure Sockets Layer certificate having a duration; (e) generating a new self-signed Secure Sockets Layer certificate when the duration has elapsed. (20) A data transfer system comprising: (a) a transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple to and receive data from an image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network via Wi-Fi or a cellular signal; (b) a cloud storage system, the cloud storage system in communication with the transfer module over the wireless network via Wi-Fi or cellular signals; (c) a user device including a display unit and a user interface; The transfer module: (i) receiving a set of medical procedure data from the image-guided surgical navigation system; (ii) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; (iii) providing the set of encrypted medical procedure data to the cloud storage system; The cloud storage system comprises: (i) receiving a request for medical procedure data from the user device; (ii) providing the set of encrypted medical procedure data to the user device; The user device, (i) receiving the encrypted medical procedure data from the cloud storage system; (ii) decrypting the medical procedure data; and (ii) displaying at least some of the medical procedure data to an end user.

Claims

1. 1. A data transfer system, comprising: (a) a transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple to and receive data from an image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network; (b) a transport server configured to provide security and authentication services associated with access to the transport module; (c) a user device having a display and a user interface, the user device in communication with the transfer module over the wireless network; The transfer module: (i) receiving a set of medical procedure data from the image-guided surgical navigation system; (ii) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; (iii) receiving a medical procedure data request from the user device; and (v) providing the set of encrypted medical procedure data to the user device; The user device, (i) storing a device key and a device key version; (ii) authenticating a user of the user device; and (iii) validating the user device based on the device key and the current key; and (iv) when the user device is not validated, prompting the user for a new key, setting it as the device key, and then deleting any information on the user device associated with the previous device key; (v) when the user device is verified as authentic and when the new key is set as the device key, receiving the set of encrypted treatment data and decrypting the set of encrypted treatment data using the device key.

2. The user device, (i) receiving a set of authentication data from the user; (ii) providing said authentication data to said forwarding server; The data transfer system of claim 1 , further configured to: (iii) authenticate the user based on an authentication response from the transfer server.

3. The user device, (i) storing a local validation database including a unique hardware identifier, a file description, an encrypted file description, and a key version, wherein the file description and the encrypted file description both describe the same file, and the encrypted file description was created from the file description using the device key; (ii) receiving a module identifier and a module key version from the transfer module; 2. The data transfer system of claim 1, further configured to: (iii) validate the user device as valid when the local validation database contains a record in which a key version in the local validation database matches the module key version and a module identifier in the local validation database matches the unique hardware identifier.

4. The user device, (i) receiving a module key version from the transfer module; 2. The data transfer system of claim 1, further configured to: (ii) verify that the user device is authentic when the module key version matches the device key version.

5. The user device, (i) storing a local validation database including a file description and an encrypted file description, the file description and the encrypted file description both describing a file stored on the transfer module, the encrypted file description being created from the file description using the device key; (ii) requesting a file portion associated with the encrypted file description from the transfer module; (iii) decrypting the file portion using the device key to create a decrypted file portion; 2. The data transfer system of claim 1, further configured to: (iv) verify that the user device is authentic if the decrypted file portion matches the file description.

6. The user device, (i) selecting a set of encrypted file names from the set of encrypted medical procedure data; (ii) if the user is authenticated and the user device is confirmed to be valid, decrypting the set of encrypted file names to create a set of decrypted file names and displaying the set of decrypted file names via the display unit; 2. The data transfer system of claim 1, further configured to: (iii) receive a selection from the user identifying one or more of the set of decrypted file names.

7. The user device, (i) decrypting a set of files from the set of encrypted medical procedure data based on the selection to create a set of decrypted files and displaying the set of decrypted files via the display; 7. The data transfer system of claim 6, further configured to: (ii) delete the set of decrypted files when the set of decrypted files is no longer displayed via the display.

8. The user device, (i) based on the selection, decrypting a set of files from the set of encrypted treatment data to create a set of decrypted files and transmitting the set of decrypted files to a secure destination associated with the user; 7. The data transfer system of claim 6, further configured to: (ii) delete the set of decrypted files after transmitting the set of decrypted files.

9. 2. The data transfer system of claim 1, wherein the wireless communication device is selected from the group consisting of a Wi-Fi transceiver, a Bluetooth transceiver, and a cellular data transceiver, the data interface is selected from the group consisting of a USB connection and an Ethernet connection, and the transfer module is a single board computer.

10. The transfer module: (i) receiving a configuration data set, the configuration data set including a previous key, a new key, and a new key version; (ii) verifying that the current key is different from the new key; and (iii) decrypting the set of encrypted medical procedure data using the previous key to create a second set of medical procedure data and deleting the set of encrypted medical procedure data; (iv) encrypting the second set of medical procedure data using the new key to create a second set of encrypted medical procedure data and deleting the second set of medical procedure data; 2. The data transfer system of claim 1, further configured to: (v) update a local configuration to make the device key version equal to the new key version and the current key equal to the new key.

11. The transfer server, (i) storing a set of email templates, each email template associated with a user, each email template configured to format the set of medical procedure data for transmission to that user; (ii) receiving a template request from the user device, the template request including an identifier and consent conditions of the user; (iii) providing to the user device an email template from the set of email templates associated with the user; (iv) storing the consent conditions; The data transfer system of claim 1 , wherein the consent conditions include a legal agreement and an indication of the user's consent to the legal agreement.

12. The transfer module: (i) providing a web server with which the user device can communicate over the wireless network; (ii) connecting to the wireless network using a static address; The data transfer system of claim 1 , wherein the wireless network is made up of peers that are either the transfer modules or the user devices.

13. The transfer module: (i) restricting the functionality of the web server to prevent use of a set of commands, the set of commands including POST, PUT, and DELETE; (ii) generating a self-signed Secure Sockets Layer certificate, the self-signed Secure Sockets Layer certificate having a duration; 13. The data transfer system of claim 12, further configured to: (iii) generate a new self-signed Secure Sockets Layer certificate when the duration has elapsed.

14. 1. A method for transferring data from an image-guided surgical navigation system, the image-guided surgical navigation system comprising: (a) installing a transfer module on the image-guided surgical navigation system, the transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple with and receive data from the image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network; (b) receiving, at the transfer module, a set of medical procedure data from the image-guided surgical navigation system; (c) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; (d) providing the set of encrypted medical procedure data to a user device, the user device having a display and a user interface, the user device in communication with the transfer module over the wireless network; (a) storing a device key and a device key version; (b) authenticating a user of the user device; (c) validating the user device based on the device key and the current key; (d) when the user device is not validated, prompting the user for a new key, setting it as the device key, and then deleting any information on the user device associated with the previous device key; (e) when the user device is validated or when the new key is set as the device key, receiving the set of encrypted medical procedure data and decrypting the set of encrypted procedure data.

15. The image-guided surgical navigation system comprises: (a) receiving a set of authentication data from the user; (b) providing said authentication data to a transfer server; (c) authenticating the user based on an authentication response from the transfer server; (d) storing a local validation database on the user device, the local validation database including a unique hardware identifier, a file description, an encrypted file description, and a key version, the file description and the encrypted file description both describing the same file, and the encrypted file description created from the file description using the device key; (e) receiving a module identifier and a module key version from the transport module; 15. The method of claim 14, further comprising: (f) validating the user device as authentic when the local validation database contains a record in which a key version in the local validation database matches the module key version and a module identifier in the local validation database matches the unique hardware identifier.

16. The image-guided surgical navigation system comprises: (a) receiving, at the transfer module, a configuration data set, the configuration data set including a previous key, a new key, and a new key version; (b) verifying that the current key is different from the new key; (c) decrypting the set of encrypted medical procedure data using the previous key to create a second set of medical procedure data and deleting the set of encrypted medical procedure data; (d) encrypting the second set of medical procedure data using the new key to create a second set of encrypted medical procedure data and deleting the second set of medical procedure data; 15. The method of claim 14, further comprising: (e) updating a local configuration of the transport module to make the device key version equal to the new key version and the current key equal to the new key.

17. The image-guided surgical navigation system comprises: (a) providing a web server on the transport module with which the user device can communicate over the wireless network; (b) connecting the transport module to the wireless network using a static address; (c) restricting the functionality of the web server to prevent use of a set of commands, the set of commands including POST, PUT, and DELETE; (d) generating a self-signed Secure Sockets Layer certificate, the self-signed Secure Sockets Layer certificate having a duration; 15. The method of claim 14, further comprising: (e) generating a new self-signed Secure Sockets Layer certificate when the duration has elapsed.

18. 1. A data transfer system, comprising: (a) a transfer module comprising a storage device, a wireless communication device, and a data interface, the data interface configured to couple to and receive data from an image-guided surgical navigation system, and the wireless communication device configured to connect to a wireless network via Wi-Fi or a cellular signal; (b) a cloud storage system, the cloud storage system in communication with the transfer module over the wireless network via Wi-Fi or cellular signals; (c) a user device including a display unit and a user interface; The transfer module: (i) receiving a set of medical procedure data from the image-guided surgical navigation system; (ii) encrypting the set of medical procedure data as a set of encrypted medical procedure data using a current key, storing the encrypted medical procedure data on the storage device, and deleting the set of medical procedure data; (iii) providing the set of encrypted medical procedure data to the cloud storage system; The cloud storage system comprises: (i) receiving a request for medical procedure data from the user device; (ii) providing the set of encrypted medical procedure data to the user device; The user device, (i) receiving the encrypted medical procedure data from the cloud storage system; (ii) decrypting the medical procedure data; and (ii) displaying at least some of the medical procedure data to an end user; The user device, (i) storing a device key and a device key version; (ii) authenticating a user of the user device; and (iii) validating the user device based on the device key and the current key; and (iv) when the user device is not validated, prompting the user for a new key, setting it as the device key, and then deleting any information on the user device associated with the previous device key; (v) when the user device is verified as authentic or when the new key is set as the device key, receiving the set of encrypted treatment data and decrypting the set of encrypted treatment data using the device key.

Images