Non-fungible token system and method for storing and accessing medical data - Patents.com

Abstract

A system and method for storing and accessing medical data in a digital filing cabinet managed by a blockchain is disclosed. The system can receive and store patient medical data from sources such as wearable devices, implants, patient devices, healthcare provider devices, databases, cloud storage accounts, medical databases, or digital filing cabinets. The system can convert the medical data into non-fungible tokens on the blockchain to protect the medical data from being accessed by unauthorized actors. The system can manage access to the medical data based on authentication rules.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 17 / 878,633, filed August 1, 2022, and U.S. Patent Application No. 17 / 678,874, filed February 23, 2022, the disclosures of which are incorporated by reference in their entireties herein.

[0002] The present disclosure relates generally to storing medical records, and more particularly to a system and method for storing and accessing medical data in a digital filing cabinet managed by blockchain. [Background technology]

[0003] Blockchain technology is used to transfer assets using tokens generated as part of the blockchain encryption process. Assets (e.g., electronic coins, blockchain-based goods, personal identifiers, etc.) are represented by a chain of transactions that transfer ownership from one party to another. To transfer ownership of an asset on the blockchain, a new transaction is generated and added to the stack of transactions in a block. To transfer ownership to a new owner as represented by the new owner's public key, the new transaction, including the new owner's public key, is digitally signed by the owner using the owner's private key. After a block is filled, it is "capped" using a block header, which is a hash digest of all transaction identifiers in the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called the "blockchain". To verify the current owner, one can follow the blockchain of transactions, verifying each transaction from the first to the last. The new owner only needs to have a private key that matches the public key of the transaction that transferred the asset. Blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key) that can be pseudo-anonymous.

[0004] Blockchain technology can maintain a distributed ledger of transactions. In a distributed ledger, a ledger of all transactions regarding an asset is stored redundantly on multiple nodes (i.e., computers) of a blockchain network. The ledger at each node is stored as a blockchain. In a blockchain, transactions are stored in the order in which they were received by the node. Each node in a blockchain network has a full replica of the entire blockchain. Blockchain systems also implement techniques to ensure that each node stores an identical blockchain, even though the nodes can receive transactions in different orders. To verify that the transactions in the ledger stored at a node are correct, the blocks in the blockchain can be accessed, from oldest to newest, to generate a new hash of the block and compare this new hash to the hash generated when the block was created. If the hashes are the same, the transactions in the block are verified. Blockchain systems also implement techniques to ensure that it is infeasible to modify transactions and regenerate the blockchain by employing computationally expensive techniques to generate nonces that are added to blocks when they are created. Because the blockchain ledger tracks all transaction outputs that have not yet been spent, this is sometimes referred to as the Unspent Transaction Output (UXTO) set.

[0005] Many types of data associated with patient treatment and records are available. To find a patient's medical records and health history, physicians often rely on collecting available patient data, such as information from the patient at the time of a medical appointment or via the patient's medical records. However, patient data may not be readily available or up-to-date, or the patient may be unconscious, for example, due to an accident. For example, information related to a surgical implant (e.g., manufacturing information, surgical procedure used, etc.) is often difficult to obtain. Thus, conventional methods for protecting a patient's medical records may lack the necessary security. Summary of the Invention

[0006] The accompanying drawings show various embodiments of the system, the method, and various other aspects of the present disclosure. Any person skilled in the art will understand that the boundaries of the elements shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. An element shown as an internal component of an element in some examples may be implemented as an external component in another example, and vice versa. Furthermore, the elements may not be drawn to scale. A non-limiting and non-exhaustive description is described with reference to the following drawings. The components in each figure are not necessarily to scale, with emphasis instead being placed on illustrating the principles. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a network connectivity diagram illustrating a system for providing patient-specific medical care, according to an embodiment. [Diagram 2] FIG. 2 illustrates a computing device suitable for use in connection with the system of FIG. 1, according to an embodiment. [Diagram 3]FIG. 1 is a system diagram illustrating an example of a computing environment in which the disclosed system operates in some embodiments. [Figure 4] FIG. 1 is a block diagram illustrating components that, in some implementations, may be used in a system employing the disclosed technology. [Diagram 5] FIG. 1 is a flow diagram illustrating a process used in some implementations to convert patient-specific medical data into non-fungible tokens. [Figure 6] FIG. 1 is a flow diagram illustrating a process used in some implementations to provide patient-specific medical data from an implant. [Figure 7] FIG. 1 illustrates an exemplary patient data set that may be used in connection with the methods described herein, according to an embodiment. [Figure 8] FIG. 1 illustrates an exemplary surgical planning report that may be used and / or generated in connection with the methods described herein, according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The present technology is directed to systems and methods for storing, managing, and accessing medical data in a digital filing cabinet managed by a distributed ledger (e.g., a public ledger) and / or a blockchain. For example, in many embodiments, the present technology is directed to providing medical data from an implant, such as a patient-specific implant. The system can receive and store patient medical data from a source (e.g., a wearable device, a user device, a blockchain device, an implant, a blockchain-enabled medical implant, a healthcare provider device, etc.). The system can convert the patient medical data into a non-fungible token. The system can manage access to the medical data based on an authentication level. The authentication level can include, but is not limited to, authenticating a user based on a geographic location, biometric data, a blockchain, a token (e.g., a non-fungible token), or any authentication method. Based on the determined authentication level of a user requesting access to medical data related to the implant, the system can allow the user to access some or all of the medical data. The system may include one or more healthcare digital filing cabinets that store medical data, patient information, electronic medical records, and / or additional patient-related information. In some embodiments, the system may share data (e.g., medical data, patient information, electronic medical records, and / or additional patient-related information) over a network without the use of digital filing cabinets.

[0009] Medical data may be managed using one or more digital filing cabinets. A user may authorize a family member, a physician, a health care provider, or other user to access selected data, types of data, data associated with a procedure, data associated with the user, and the like. A digital filing cabinet may include, for example, surgical plans, implant data, health records, health insurance information, digital wallets, and other medical data. In some implementations, a digital filing cabinet may automatically update medical data based on received data. In some implementations, a digital filing cabinet may automatically receive data from a user device, such as a wearable device, a smartphone, non-fungible tokens (NFTs), or other device that may collect a user's biometrics. A user's digital filing cabinet may link one or more accounts to provide communication between the accounts. For example, an account may be a health care provider account, a family member account, an insurance company account, a government agency account, or other accounts that allow the digital filing cabinet to request and receive data. A user can manage third-party access (e.g., view only, edit, annotate, etc.) of data stored within an NFT (e.g., a containerized NFT), data linked by an NFT (e.g., data linked to an NFT), etc. This allows, for example, a user to allow a physician to access and view data collected in real time or near real time. A physician can provide real time or near real time feedback to a patient via a digital filing cabinet. A patient can use a digital filing cabinet or patient account to review, for example, physician feedback, diagnoses, treatment plans (e.g., surgery plans, intervention plans, treatment plans, etc.), predicted treatment outcomes, cost estimates, insurance information, etc.

[0010] The data management system may, in response to a failed authorization attempt, lock the digital filing cabinet, notify the user of possible fraud, fraudulent activity, etc. The data management system may analyze the collected data to generate a post-treatment plan. In some embodiments, the data management system may use one or more models to analyze the data collected after surgery to generate or modify a post-treatment plan, such as a treatment plan, a new surgery plan, etc. The post-operative analysis may be stored in the digital filing cabinet or other database. This allows the data management system to periodically or continuously analyze data from various data sources to provide patient-specific medical care. The data management system may select the selected model (e.g., machine learning model) based on the available data. When new data becomes available, the data management system may identify one or more models that are suitable for analyzing the newly available data. This allows the data management system to adaptively select machine learning models to improve the analysis. Data sources may include, but are not limited to, diagnostic equipment (e.g., imaging equipment), patient wearables, hospital diagnostic equipment, etc.

[0011] In some embodiments, the medical management system includes a digital filing cabinet that consolidates data from, for example, a digital wallet, one or more devices associated with the user, or data sources associated with the physician / healthcare provider. The medical management system can generate post-operative analytics that can be used based on post-operative data such as new scans of the patient, diagnostic data, new patient medical records, etc. The medical management system can manage authentication, the patient's wallet, and / or the digital filing cabinet, for example, with automated settings, privacy management, updated record management, etc.

[0012] In some embodiments, the point-of-care device may be integrated with a medical management system. Data from the point-of-care device may be automatically transmitted to a patient's digital filing cabinet. This allows the patient to access a digital filing cabinet (e.g., a digital filing cabinet managed by the implant manufacturer, a digital filing cabinet managed by the medical provider, etc.) and view and / or manage the data in real time or near real time.

[0013] In some embodiments, the medical management system can use blockchain with NFT technology to store medical data and authenticate access to the medical data. The medical management system can use blockchain technology to convert medical data (e.g., patient information, surgery details, imaging studies, EMR, implant information, and / or additional patient related information) into NFTs. The medical management system can create digital keys for each user (e.g., patient, medical provider, insurance company, family member, etc.) and rules (e.g., smart contracts) regarding permissions to access the medical data. By converting the medical data into NFTs, the user's medical data can be protected from being accessed by unauthorized actors or unauthorized users. For example, because the NFT is digitally stored on the blockchain, the NFT is immutable (e.g., cannot be changed) and distributed (e.g., output validation is confirmed by the blockchain network), making it difficult for unauthorized actors to access the medical data. The NFT can include metadata that contains the medical data stored on-chain or off-chain. In some embodiments, a containerized NFT can store the data on the blockchain. The medical data can be converted into a containerized NFT that contains the medical data in a distributed ledger. In some implementations, medical NFTs store large files, such as imaging data, scans, etc., on a distributed ledger. The large files may be tokenized (e.g., compressed, converted, etc.) into medical NFTs or distributed among multiple medical NFTs. For example, a medical NFT configuration may be selected to store metadata, medical data, containerized data, surgical procedure data, medical device data, or other data disclosed herein.

[0014] In some embodiments, the medical data may be linked to the NFT. For example, at least a portion of the medical data and the linked NFT may be stored on different blockchains. In some implementations, a first portion of the medical data may be stored as containerized data as part of a first NFT on a first blockchain. A second NFT may be linked to a second portion of the medical data stored on a second blockchain. In some embodiments, the medical data may be stored in a distributed storage system, a centralized storage system, or the like. For example, a non-fungible token platform may automatically link stored patient medical data to a newly created NFT that includes one or more links to metadata, medical data, or other data disclosed herein. A non-fungible token platform ("NFT platform") may determine the location of the NFT-linked data based on, for example, one or more of file size, authentication level, encryption, hashing protocol, smart contract, or the like. For example, large file-sized, NFT-linked medical data (e.g., high-resolution imaging, scans, etc.) may be stored in a distributed or centralized digital filing cabinet managed, for example, by a medical provider, hospital, or the like. The small file size of the medical data linked to the NFTs may be stored on a blockchain or ledger. In some implementations, the user may select the location where the data associated with the NFT is stored, and the NFT and data associated with the NFT may be stored using distributed storage (e.g., an interplanetary file system), a peer-to-peer hypermedia protocol, an NFT platform or NFT marketplace, or other system. The medical data NFT platform may include multiple NFT platforms, each configured to create and manage NFTs according to different protocols.

[0015] Without being bound by theory, it is expected that using a medical data management platform to perform various aspects of the surgical planning described herein will provide multiple advantages over traditional surgical techniques. For example, storing, analyzing, managing, and accessing medical data in a digital filing cabinet can improve data security of patient information, reduce patient recovery time by providing patients with access to health indicators and areas for improvement, reduce pre- and post-procedure patient stress by having access to medical information (e.g., x-ray images, treatment routines, etc.), reduce patient analysis / evaluation time as medical providers have real-time or near real-time access to patient information from the patient's implants, and alert patients and medical providers to implant updates or recalls from implant manufacturers.

[0016] In an exemplary embodiment, the methods described above may be performed by a system storing computer-executable instructions that, when executed, cause the system to perform the steps of the method.

[0017] In some embodiments, the computer-implemented method includes linking to a patient-controlled account storing patient data associated with the patient-specific implant. The method includes receiving the patient data from the patient-controlled account. The received patient data is analyzed to identify associated training parameters. A reference data set is generated based on the associated training parameters. A machine learning model is trained at least in part on the reference data set to design an implant similar to the patient-specific implant. In some embodiments, the associated training parameters can be a classified spinal condition, the classification being based on one or more predefined thresholds. The predefined thresholds can include a threshold level-specific lumbar lordosis, a threshold Cobb angle, a threshold pelvic intrinsic angle, and / or a threshold disc height. In some embodiments, the received patient data includes at least one of comparing the received patient data to the patient's pre-operative data or identifying at least a portion of the patient data with respect to the reference data set based on the comparison. Embodiments of the present disclosure are described more fully hereinafter with reference to the accompanying drawings, in which like numerals represent like elements throughout the several views and in which example embodiments are shown. However, the claimed embodiments may be embodied in various forms and should not be construed as being limited to the embodiments set forth herein, which are non-limiting examples and merely examples, among other possible examples.

[0018] The words "comprising," "having," "including," and "including," as well as other forms of these words, are intended to be equivalent in meaning and are intended to be open-ended in that the item or items following any one of these words are not intended to be an exhaustive list of such item or items, nor are they intended to be limited to only the listed item or items.

[0019] As used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0020] While the disclosure herein primarily describes systems and methods for storing and accessing medical data in digital filing cabinets associated with implants, plans (e.g., surgical plans, treatment plans, etc.), the technology may be similarly applied to medical techniques and medical devices in other fields (e.g., other types of medical practices) that may or may not utilize digital filing cabinets. Additionally, while many embodiments herein describe systems and methods related to implanted devices, the technology may be similarly applied to other types of medical techniques and medical devices (e.g., non-implanted devices).

[0021] FIG. 1 is a network connectivity diagram illustrating a computing system 100 for storing medical data in a digital filing cabinet and accessing medical data, according to an embodiment. As described in further detail herein, the system 100 is configured to collect, store, monitor, and / or update medical data. The system 100 can include one or more digital filing cabinets 180, which can include, without limitation, one or more electronic health records (EHRs), EMRs, patient information, digital wallets (e.g., signed messages, keys, cryptocurrencies, tokens, credit cards, payment information, etc.), and other medical data. The digital filing cabinets 180 can receive and convert the medical data into a digital format to improve the efficiency of finding and retrieving the medical data.

[0022] The computing system 100 can function as a crypto platform. The digital filing cabinet 180 can convert medical data into crypto tokens using blockchain technology. In some embodiments, the computing system 100 is configured to operate as an NFT platform based on blockchain technology. The use of blockchain technology can improve the security of medical data based on the authentication requirement of the user to access the data. NFTs can achieve the validation of digital medical data by authenticating the access credentials (e.g., public and private keys), eliminating data tampering (data integrity), and providing a source of truth for the patient's health records. NFTs can enable data ownership, data accessibility, data portability, patient-specific solutions based on verifiable patient data, patient-specific algorithms for treatment, patient-selectable sharing of data, traceable use of patient data, and can create economic value for the use of data. The use of blockchain technology and NFTs can provide the system 100 with a method to securely track, identify ownership, link to medical data, and / or transfer medical data (e.g., to the intended recipient). In some embodiments, NFTs can include expiration dates to access data, verification of intended recipients, instructions for implant treatments (e.g., surgical robots), traceable chain of custody (e.g., supply chain) to ensure authenticity of data (no counterfeits), and payment for products (verified and traceable) in cryptocurrency (repayment).

[0023] The digital filing cabinet 180 may receive medical data from a patient, a healthcare provider, a healthcare insurer, a financial institution, and / or a storage device containing medical data. Based on the type of medical data, the digital filing cabinet 180 may organize the medical data by authorization level. For example, a patient may have access to all medical data, while a healthcare provider may be limited to medical records and may not have access to the patient's medical insurance or payment information. The digital filing cabinet 180 includes patient medical data 108 and organizes the patient medical data by different authorization levels, such as data 108a, 108b, 108c, and 108d. Each group or set of medical data 108a, 108b, 108c, and 108d requires a different level of authentication for a user to access. Exemplary medical data sets and medical data are described in connection with FIGS. 7-8. After the user's authorization level is identified, the system 100 may transmit to the user the medical data associated with the identified authorization level. In some implementations, the system 100 transmits the medical data to the patient's implant 150 (e.g., a distributed ledger enabled medical implant, a blockchain enabled medical implant, etc.) for retrieval by a user or to a user device. The implant 150 can include memory storage for storing the medical data. The implant 150 can include a wireless communication device such as a chip (e.g., a Bluetooth chip or a Near Field Communication (NFC) chip) so that the user device can wirelessly receive the medical data from the implant 150. The implant 150 can transmit the medical data in an encrypted form, and the user can decrypt the medical data. In some implementations, the computing system 100 can generate and transmit a code (e.g., QR, RFID, etc.) that the user can scan to access the medical data on the implant 150.

[0024] The number of groups of medical data, permission settings, data stored, organization scheme, and / or other configurations may be set by a user, a medical provider, etc. Data may be automatically collected and organized into appropriate groups of data. In a cloud-based implementation, the digital filing cabinet 180 may be stored on a cloud server to provide remote access. In some implementations, the digital filing cabinet 180 may be stored locally to provide access to records at any time. Additionally, the local storage of the digital filing cabinet 180, including the digital wallet containing the blockchain information, may be stored locally. Each group of medical data 108a, 108b, 108c, and 108d may be associated by the user (or data management system) with, for example, a procedure, a physician, a medical provider, and / or a medical manufacturer. The user may add information, including annotations, personal notes, and other information, which may or may not be viewable by other users, to the medical data 108a, 108b, 108c, and 108d, and may select the type, amount, and / or level of permission / access. In some implementations, the medical data 108a, 108b, 108c, and 108d may include blockchain data, wallets, NFTs, data linked to NFTs, containerized data, keys, unique IDs, encryption programs, and the like.

[0025] In some embodiments, the group of medical data 108a can be associated with an implant 150 in a patient (not shown) and can include a surgical plan for the implant 150, manufacturing data for the implant 150, notifications (e.g., recall notifications), predicted post-treatment analysis, physician information, and other information associated with the implant 150 or procedure (e.g., pre-operative, intra-operative, and / or post-operative information). A user can set one or more rules to allow authorized users to access the medical data 108a or the medical data 108 (e.g., all or a portion of). For example, a user can allow a physical therapist to view the post-operative data 108a, and the physical therapist can access the data collected after surgery to modify the user's treatment plan. A user can allow a family doctor's access to the medical data 108 to provide general treatment, and a surgeon's access to the medical data 108a to evaluate surgery results and recommend additional treatments, such as future surgical interventions.

[0026] The medical data 108b may include, for example, the patient's general electronic medical records (EMR), including health records not associated with the implant. The user may allow a family doctor's access to the medical data 108b to provide general care. The user may allow family members and third parties access to the medical data 108b. Thus, the access settings for the medical data 108a and 108b may be the same or different.

[0027] The medical data 108c may include, for example, data from user device input. The data may be, for example, data from wearables (e.g., smart watches, pedometers, etc.), smartphones, biometric sensors (e.g., analyte sensors, glucose sensors, etc.), heart monitors, exercise monitoring equipment, etc. A user may allow a family member to access the data 108c, for example, to aid in adherence to diet goals, exercise goals, or other user goals.

[0028] The data may be automatically provided to the digital filing cabinet 180. In some embodiments, for example, the implant's search function 160 may provide instructions for accessing the digital filing cabinet 180. An imaging device (e.g., an MRI machine, an X-ray machine, a scanner, etc.) may read the information from the search function 160. The contained information may be transmitted to the digital filing cabinet 180 via the communications network 104. The transmitted information may include, without limitation, authorization information (e.g., digital filing cabinet login information), patient identification information, implant identifiers, and / or other information for use in authorizing, locating, and / or classifying the data.

[0029] The digital filing cabinet 180 can store data transmitted from the manufacturing system 124 via the communication network 104, analyze the received data, and correlate data, such as manufacturing data, with the received implant data. Correlation settings can be changed or set by a user. Additionally, a surgical plan can be transmitted from the system 106 via the communication network 104 to the digital filing cabinet 180. The surgical plan can be associated with the manufacturing data, implant data, and other information associated with the implant 150. The digital filing cabinet 180 can transmit patient medical data to the system 106 via the communication network 104. This allows newly available data to be automatically or periodically transmitted to the analysis system 106. The analysis system 106 can, for example, analyze the newly received data using one or more models and provide analysis results to the client computing device 102, the digital filing cabinet 180, the manufacturing system 124, a physician, etc. The client computing device 102 can receive analysis results and notifications, for example, from the digital filing cabinet 180, the analysis system 106, and / or other data sources.

[0030] In some embodiments, the system 100 is configured to manage patient medical data on a user device, a cloud-based device, and / or a healthcare provider device. The medical data can include patient medical records, medical insurance information, health metrics from wearable devices, surgery information, surgery plans, technique recommendations (e.g., device and / or instrument recommendations), and / or medical device information (e.g., implanted medical devices (e.g., also referred to herein as "implants" or "implanted devices") or implant-delivered instruments). The digital wallet can be used to manage blockchain medical data (e.g., blockchain EHR, EMR, etc.), insurance actions (e.g., payments, claims submissions, etc.), and the like.

[0031] In some embodiments, the system 100 manages the authentication required to access the medical records. The authentication may include a blockchain, a token, a key, biometrics, a geographic location, a password, or any authentication information. Medical data that is specific to a patient is referred to herein as "patient-specific" or "personalized" medical data. The digital filing cabinet 180 may store one or more keys (e.g., private key, public key, etc.), authentication information, and / or other information for accessing data, including electronic medical records associated with a patient, from a distributed blockchain ledger of electronic medical records. U.S. Patent Application No. 17 / 463,054 discloses a system and method for tracking patient medical records, for example, using keys, and is incorporated by reference in its entirety. The system 100 may include systems and functions for linking medical devices with patient data, as disclosed in U.S. Patent Application No. 16 / 990,810, which is incorporated by reference in its entirety. The digital filing cabinet may be used to receive user feedback, as described in U.S. Patent Application No. 16 / 699,447, which is incorporated by reference in its entirety. The system disclosed herein can include a digital filing cabinet for designing medical devices using the methods disclosed in US patent application Ser. No. 16 / 699,447.

[0032] The system 100 includes a client computing device 102, which can be a user device, such as a smartphone, a mobile device, a laptop, a desktop, a personal computer, a tablet, a phablet, a wearable device (e.g., a smart watch), or other device as known in the art. As described further herein, the client computing device 102 can include one or more processors and a memory storing instructions executable by the one or more processors to perform the methods described herein. The client computing device 102 can be associated with a healthcare provider or a patient. Although FIG. 1 illustrates a single client computing device 102, in alternative embodiments, the client computing device 102 can instead be implemented as a client computing system encompassing multiple computing devices, such that the operations described herein with respect to the client computing device 102 can instead be performed by a computing system and / or multiple computing devices.

[0033] The client computing device 102 is configured to receive patient medical data 108 associated with a patient. The patient medical data 108 may include data representing the patient's condition, anatomy, medical condition, medical history, preferences, and / or any other information or parameters related to the patient. For example, patient medical data 108 may include medical history, surgical intervention data, treatment outcome data, progress data (e.g., physician's notes), patient feedback (e.g., quality of life questionnaires, feedback obtained using surveys), clinical data, provider information (e.g., physician, hospital, surgical team), patient information (e.g., demographics, gender, age, height, weight, type of medical condition, occupation, activity level, organizational information, health assessment, comorbidities, health related quality of life (HRQL)), vital signs, diagnosis results, medication information, allergies, imaging data (e.g., camera images, Magnetic Resonance Imaging (MRI) images, ultrasound images, Computerized Aided Tomography (CAT) scan images, Positron Emission Tomography (PET) images, X-ray images), diagnostic equipment information (e.g., manufacturer, model number, specifications, user selected settings / configuration, etc.), and the like. In some embodiments, the patient medical data 108 includes data representing one or more of a patient identification number (ID), age, sex, body mass index (BMI), lumbar lordosis, Cobb angle, pelvic intrinsic angle, disc height, segmental flexibility, bone quality, rotational displacement, range of motion, disability score, and / or spinal treatment level. In some embodiments, the client computing device 102 may store the digital filing cabinet 180, the medical data 108, and / or other information locally.The client computing device 102 can store account information to allow a user to automatically access a remote digital filing cabinet or account with or without login credentials. In some embodiments, the client computing device 102 can periodically or continuously receive newly available data (e.g., biometrics from a wearable, user input, etc.) and can transmit all or a portion of the newly available data to a remote storage system, such as, for example, a digital filing cabinet 180, a server 106, etc.

[0034] The client computing device 102 is operatively connected to the server 106 via a communication network 104, thus enabling data transfer between the client computing device 102 and the server 106. The communication network 104 may be a wired network and / or a wireless network. If the communication network 104 is wireless, it may be implemented using communication technologies such as Visible Light Communication (VLC), Worldwide Interoperability for Microwave Access (WiMAX), Long term evolution (LTE), Wireless local area network (WLAN), Infrared (IR) communication, Public Switched Telephone Network (PSTN), radio waves, and / or other communication technologies known in the art.

[0035] The server 106, sometimes referred to as a "medical data network" or a "medical data analysis network," may include one or more computing devices and / or systems. As further described herein, the server 106 may include one or more processors and memory storing instructions executable by the one or more processors to perform the methods described herein. In some embodiments, the server 106 is implemented as a distributed "cloud" computing system or functionality across any suitable combination of hardware and / or virtual computing resources.

[0036] The cloud analytics integration platform 126 is connected to the communication network 104. The analytics integration platform 126 can analyze medical data and integrate data collected from patients and healthcare providers into a digital filing cabinet. The analytics integration platform 126 can integrate surgical plans and patient plans, identify important health indicators for patients, display patient information and goals, perform post-operative analysis, and generate notifications to healthcare providers or patients (e.g., monitor based on data from wearables, request updated information, schedule appointments, or notify of emergencies).

[0037] The medical implant 150 can be an intervertebral device including a body 152 configured to interface with one or more identified anatomical structures (e.g., one or more vertebral bodies or vertebral endplates) at and / or proximate to a targeted implant treatment site (e.g., between one or more vertebral bodies or vertebral endplates). The implant body 152 can include one or more structural features designed to mate with the one or more identified anatomical structures. For example, in the illustrated embodiment, the implant 150 can include an upper surface 165 and an lower surface (not shown) configured to be secured to a vertebral body of the spine. In some embodiments, the upper surface 165 and the lower surface can have contours that match the contours of the vertebral endplates such that the upper surface 165 and the lower surface "mate" with the corresponding vertebral endplates with which they mate. The dimensions, contours, topology, composition, and / or other implant data can be part of the EMR. In some embodiments, such as the illustrated embodiment, the upper surface 165 and / or the lower surface can be textured (e.g., by roughening, knurling, ridges, etc.). The texture data can be part of the manufacturing data stored in the EMR. For lordosis correction, the upper surface 165 and the lower surface can be angled relative to one another, and the EMR can include the angle and size of these surfaces.

[0038] A user (e.g., a physician, a healthcare provider, a patient, etc.) can access the EMR using a search function 160. For example, in an embodiment where the search function 160 is a barcode corresponding to a unique identifier, the user can scan the search function 160, for example, using one or more cameras on the computing device, and / or otherwise enter the unique identifier into the computing device. After the unique identifier is entered into the computing system, the computing system can transmit the unique identifier to a remote server (e.g., over a communications network) along with a request to provide a medical data set specific to the corresponding patient. In response to the request, as described above, the server can locate the particular data set associated with the unique identifier and transmit the data set to the computing device for display to the user. The implant 150 can include other functionality to assist in accessing the ledger and viewing the EMR.

[0039] The search function 160 may be used to carry patient data, such as one or more NFTs, keys (e.g., a private key for unlocking patient medical records stored in the blockchain ledger), or blockchain data. The medical implant 150 may be blockchain-enabled to establish communication contact using a proximity mode of communication. The private key stored in the search function 160 may be used to access medical data specific to the patient. In some implementations, the medical implant 150 also includes a private blockchain ledger to track the EMR associated with the patient. As the patient undergoes various treatments, new and updates to the patient's existing EMR are generated and stored as "transactions" in the blockchain ledger. To access the EMR associated with the patient, the private key from the medical implant 150 must be used to "unlock" the EMR stored in the blockchain ledger. The patient may provide this private key to the healthcare provider and other parties by a secure platform, a mobile application, a digital key, etc. In some embodiments, the EMR is encrypted using an encryption key that the healthcare provider decrypts. Additionally or alternatively, key change protocols, certificate management protocols (e.g., registration certificate protocol, transaction certificate protocol, etc.), and other protocols may be utilized for variable access and authorization. Patients can manage the data in their EMR to share only selected data. For example, a patient can share one section of the EMR while keeping another section private. The system also allows for user controlled settings, such as settings for minors, family members, relatives, and / or settings controlled by other users.

[0040] The EMR may include patient data associated with the implant design and design process. If the implant is an artificial disc, for example, the stored data may include kinematic data (e.g., pre-op patient data, target kinematic data, etc.), manufacturing data, design parameters, target life data, physician recommendations / notes, etc. The disc may include an articulating implant body including plates contoured to match vertebral endplates, custom articulating members between the plates to provide patient specific motion, etc. If the implant is an interbody cage, the stored data may include implant body material specifications, implant body dimensions, manufacturing data, design parameters, target life data, physician recommendations / notes, etc. Applications and patents incorporated by reference disclose data that may be associated with the search function 160 (e.g., surgical plans, implant specifications, data sets, etc.).

[0041] In some implementations, patients can set variable permissions regarding access to transactions and details stored in the blockchain ledger. For example, a particular medical provider may only be given access to certain transactions related to certain types of medical procedures. In other implementations, permissions may be set based on the patient, including a child-specific setting for children with implants.

[0042] The medical implant 150 can also track and monitor various health-related data of the patient. For example, the medical implant 150 can include one or more sensors configured to measure pressure, load, or force exerted by an anatomical element, for example to monitor activity, load, and the like. The medical implant 150 can continuously or periodically collect data indicative of activity levels, activities performed, disease progression, and the like. For example, load on the implant 150 over a period of time can be tracked. Applications and patents incorporated by reference disclose techniques for monitoring and collecting data and transmitting data. In some embodiments, the medical implant 150 can identify events such as excessive load, spinal imbalance, and the like. In some embodiments, patients are monitored based on activities (e.g., surgical procedures, changes in condition, and the like), disability (e.g., new disability, disability progression, and the like), and / or medical events with automatic blockchain updates. Medical events can include imaging, diagnosis, treatment, and / or outcomes, as well as event data that can be encoded within the blockchain. The collected data can be used as past patient data used to treat another patient. The applications and patents incorporated by reference also disclose the use of historical data, imaging data, surgical plans, simulations, modeled results, treatment protocols, and outcome values ​​that may be encoded within the blockchain. The digital filing cabinet may also track and monitor various health-related data of the patient and may include one or more digital wallets, such as a blockchain digital wallet, a ledger wallet, etc., for managing the blockchain data. The number, configuration, and / or contents of the digital wallets may be selected by a user, a physician, etc. The digital wallets may be used to access and automatically update the blockchain for any number of implants.

[0043] In some implementations, more than one implant may be used. For example, a patient may have both a spinal implant that includes an encoded chip that includes a private blockchain ledger that includes a private key and / or the patient's EMR, and a subcutaneous digital implant. The subcutaneous digital implant acts as an intermediate device and communicates with both the spinal implant that includes the private key and / or the private blockchain ledger, and an external computing device, such as a patient care computing system. The subcutaneous digital implant may include its own data, such as patient identification information, biometric data, etc. In some embodiments, the subcutaneous digital implant may include a private blockchain ledger that includes a private key and / or the patient's EMR. The patient-specific implant may be any of the implants described herein or any of the patent references incorporated herein by reference. For example, a patient-specific implant can include one or more of a screw (e.g., bone screw, spinal screw, pedicle screw, facet screw), interbody implant device (e.g., interbody implant), cage, plate, rod, disc, fusion device, spacer, bar, expandable device, stent, bracket, lanyard, scaffold, fixation device, anchor, nut, bolt, rivet, connector, tether, fastener, joint replacement (e.g., artificial disc), hip implant, etc. A patient-specific implant design can include data representing one or more of the implant's physical properties (e.g., size, shape, volume, material, mass, weight), mechanical properties (e.g., stiffness, strength, modulus, hardness), and / or biological properties (e.g., osteointegration, cell adhesion, antibacterial properties, antiviral properties). For example, an orthopedic implant design can include the implant's shape, size, material, and / or effective stiffness (e.g., lattice density, number of struts, position of struts, etc.).

[0044] Additional implant types, configurations, and structural features suitable for mating with the identified anatomical features are described, for example, in U.S. Patent Application No. 16 / 207,116, filed December 1, 2018, and U.S. Patent Application No. 16 / 987,113, filed August 6, 2020, the disclosures of which are incorporated herein by reference in their entireties. For example, the medical implant can be a pedicle screw, a patient-specific implant, an interbody implant system, an artificial disc, an expandable interbody implant, a sacroiliac joint implant, a plate, an arthroplasty device for an orthopedic joint, a non-structural implant, or other device disclosed in the patents and applications incorporated herein by reference.

[0045] The medical implant 150 may be used to track and monitor medical data associated with a patient. U.S. Patent Application No. 63 / 218,190 discloses an implant that can collect data, assign weights / values, and communicate with other devices. Monitoring may be used with normative systems such as those disclosed in U.S. Patent No. 10,902,944 and U.S. Patent Application No. 17 / 342,439, which are incorporated by reference in their entirety. For example, the patient's data may be incorporated into one or more training sets for machine learning systems or other systems disclosed in the patents and applications incorporated by reference. The medical implant 150 may also be a multi-purpose implant that provides a structure to address a medical problem within the patient's body while also carrying information about the patient. For example, the medical implant 150 may be a pacemaker, a plate or pin to properly position a previously fractured bone or set of bones, etc. The NFTs may be used to store, track, authenticate, transmit, and / or process data disclosed in U.S. Patent No. 10,902,944 and U.S. Patent Application No. 17 / 342,439. For example, NFTs may be used to manage surgical plans, pre-operative data, post-operative data, outcome analysis, implant designs, transactions, medical data, etc. The digital filing cabinet 180 may also be incorporated into the systems disclosed in U.S. Patent No. 10,902,944 and U.S. Patent Application No. 17 / 342,439 to track and monitor medical data managed by patients.

[0046] The client computing device 102 and the server 106 may individually or collectively perform various methods described herein for storing and retrieving medical data. For example, some or all of the steps of the methods described herein may be performed by the client computing device 102 alone, the server 106 alone, or a combination of the client computing device 102 and the server 106. In some embodiments, the client computing device 102 includes one or more digital filing cabinets 180. Thus, although certain operations are described herein with respect to the server 106, it should be understood that these operations may also be performed by the client computing device 102 and vice versa.

[0047] The server 106 includes at least one database 110 configured to store reference data useful for providing, managing, or analyzing patient-specific medical data from the implant methods described herein. The reference data can include historical and / or clinical data from the same or other patients, data collected from previous surgeries and / or other treatments of the patient by the same or other healthcare providers, data related to medical device design, data collected from testing or research groups, data from practice databases, data from academic institutions, data from implant manufacturers or other medical device manufacturers, data from imaging studies, data from simulations, clinical trials, demographic data, treatment data, outcome data, mortality, etc.

[0048] In some embodiments, the database 110 includes multiple reference patient data sets, each patient reference data set associated with a corresponding reference patient. For example, the reference patients can be patients who have previously undergone treatment or are currently undergoing treatment. Each reference patient data set can include data representing the corresponding reference patient's condition, anatomy, medical condition, medical history, disease progression, preferences, and / or any other information or parameters related to the reference patient, such as any of the data described herein with respect to the medical data 108. In some embodiments, the reference patient data set includes pre-operative data, intra-operative data, and / or post-operative data. For example, the reference patient data set can include data representing one or more of a patient ID, age, sex, BMI, lumbar lordosis, Cobb angle, pelvic intrinsic angle, disc height, segmental flexibility, bone quality, rotational displacement, and / or spinal treatment level. As another example, the reference patient data set can include treatment data related to at least one treatment procedure performed on the reference patient, such as a description of a surgical procedure or intervention (e.g., a surgical technique, a bone resection, a surgical operation, a corrective operation, a placement of an implant or other device). In some embodiments, the treatment data includes medical device design data of at least one medical device used to treat the reference patient, such as physical properties (e.g., size, shape, volume, material, mass, weight), mechanical properties (e.g., stiffness, strength, modulus, hardness), and / or biological properties (e.g., osteointegration, cell adhesion, antibacterial properties, antiviral properties). In yet another example, the reference patient dataset can include outcome data describing the results of the treatment of the reference patient, such as corrected anatomical indices, presence of fusion surgery, HRQL, activity level, return to work, complications, recovery time, efficacy, mortality, and / or reoperation.

[0049] In some embodiments, the server 106 receives at least a portion of the reference patient dataset from a plurality of healthcare provider computing systems (e.g., systems 112a-112c, collectively 112), a digital filing cabinet, or a combination thereof. The server 106 may be connected to the healthcare provider computing systems 112 via one or more communication networks (not shown). Each healthcare provider computing system 112 may be associated with a corresponding healthcare provider (e.g., a doctor, a surgeon, a clinic, a hospital, a healthcare network, etc.). Each healthcare provider computing system 112 may include at least one reference patient dataset (e.g., reference patient datasets 114a-114c, collectively 114) associated with a reference patient treated by the corresponding healthcare provider. The reference patient dataset 114 may include, for example, an electronic medical record, an electronic health record, a biomedical dataset, etc. The reference patient dataset 114 may be received by the server 106 from the healthcare provider computing systems 112 and may be reformatted into different formats for storage in the database 110. Optionally, the reference patient dataset 114 may be processed (e.g., purified) to ensure that the patient parameters represented are likely to be useful for the treatment planning methods described herein.

[0050] As described in further detail herein, the server 106 may be configured with one or more algorithms to generate patient-specific treatment plan data (e.g., treatment procedures, medical devices) based on the reference data. In some embodiments, the patient-specific data is generated based on a correlation between the patient dataset 108 and the reference data. Optionally, the server 106 may predict outcomes, including recovery time, efficacy based on clinical endpoints, likelihood of success, predicted mortality, predicted associated reoperations, etc. In some embodiments, the server 106 may continuously or periodically analyze patient data (including patient data obtained during the patient's stay) to determine near real-time or real-time risk scores, mortality predictions, etc.

[0051] In some embodiments, the server 106 includes one or more modules for performing one or more steps of the patient-specific treatment planning methods described herein. For example, in the embodiment shown, the server 106 includes a data analysis module 116 and a treatment planning module 118. In alternative embodiments, one or more of these modules may be combined with one another or omitted. Thus, although certain operations are described herein with respect to a particular module or modules, this is not intended to be limiting and in alternative embodiments, such operations may be performed by a different module or modules.

[0052] The data analysis module 116 is configured with one or more algorithms to identify a subset of reference data from the database 110 that is likely to be useful in developing a patient-specific treatment plan. The database 110 may retrieve or receive data from the client computing device 102, the digital filing cabinet 180, or other data sources. For example, the data analysis module 116 may compare the patient-specific data (e.g., the patient data set 108 received from the client computing device 102) with reference data (e.g., the reference patient data set) from the database 110 to identify similar data (e.g., one or more similar patient data sets in the reference patient data set). The reference data may be updated in real-time or near real-time using other patient data accessible via the network 104. The comparison may be based on one or more parameters, such as age, sex, BMI, lumbar lordosis, pelvic intrinsic angle, and / or treatment level. These parameters may be used to calculate a similarity score for each reference patient. The similarity score may represent a statistical correlation between the patient data set 108 and the reference patient data set. Therefore, similar patients can be identified based on whether the similarity score is higher, lower, or at a specified threshold.For example, as described in more detail below, this comparison can be performed by assigning a value to each parameter and determining the sum of the differences between the subject patient and each reference patient.The reference patients whose sum of differences is lower than the threshold can be considered to be similar patients.

[0053] The data analysis module 116 may further be configured with one or more algorithms to select a subset of the reference patient dataset based on, for example, similarity to the patient dataset 108 and / or treatment outcomes of the corresponding reference patients. For example, the data analysis module 116 may identify one or more similar patient datasets in the reference patient dataset and then select the subset of similar patient datasets based on whether the similar patient datasets include data indicative of beneficial or desirable treatment outcomes. The outcome data may include data representing one or more outcome parameters, such as corrected anatomical indices, presence of fusion, HRQL, activity level, complications, recovery time, efficacy, mortality, or reoperation. As described in more detail below, in some embodiments, the data analysis module 116 calculates an outcome score by assigning a value to each outcome parameter. If the outcome score is higher, lower, or at a specified threshold, the patient may be considered to have a beneficial outcome.

[0054] In some embodiments, the data analysis module 116 selects the subset of reference patient datasets based at least in part on user input (e.g., from a clinician, surgeon, physician, or health care provider). For example, the user input may be used to identify similar patient datasets. In some embodiments, weightings of the similarity and / or outcome parameters may be selected by the health care provider or physician to adjust the similarity and / or outcome score based on the clinician's input. In further embodiments, the health care provider or physician may select the set of similarity and / or outcome parameters (or define new similarity and / or outcome parameters) used to generate the similarity and / or outcome score, respectively.

[0055] In some embodiments, the data analysis module 116 includes one or more algorithms used to select a set or subset of reference patient datasets based on criteria other than patient parameters. For example, one or more algorithms may be used to select a subset based on provider parameters (e.g., based on provider rankings / scores, such as hospital / physician expertise, number of procedures performed, hospital rankings, etc.) and / or medical resource parameters (e.g., diagnostic equipment, facilities, surgical equipment, such as surgical robots), or other non-patient related information that may be used to predict outcomes and risk profiles for the current provider's procedures. For example, reference patient datasets including images captured from similar diagnostic equipment may be aggregated to reduce or limit irregularities due to variations between diagnostic equipment. Additionally, patient-specific treatment plans may be developed for a particular provider using data from similar providers (e.g., providers that traditionally have similar outcomes, physician expertise, surgical teams, etc.). In some embodiments, reference provider datasets, hospital datasets, physician datasets, surgical team datasets, post-treatment datasets, and other datasets may be utilized. As an example, a patient-specific treatment plan for performing a battlefield surgery can be based on reference patient data from similar battlefield surgeries and / or datasets associated with battlefield surgeries. In another example, a patient-specific treatment plan can be generated based on available robotic surgery systems. The reference patient dataset can be selected based on patients operated on using comparable robotic surgery systems according to similar conditions (e.g., surgical team size and capabilities, hospital resources, etc.).

[0056] The treatment planning module 118 is configured using one or more algorithms to generate at least one treatment plan (e.g., a pre-operative plan, a surgical plan, a post-operative plan, etc.) based on the output from the data analysis module 116. In some embodiments, the treatment planning module 118 is configured to develop and / or implement at least one predictive model, also known as a "prescriptive model," to generate a patient-specific treatment plan. The predictive model may be developed using clinical knowledge, statistics, machine learning, AI, neural networks, etc. In some embodiments, the output from the data analysis module 116 is analyzed (e.g., using statistics, machine learning, neural networks, AI) to identify correlations between data sets, patient parameters, healthcare provider parameters, healthcare resource parameters, treatment procedures, medical device designs, and / or treatment outcomes. These correlations may be used to develop at least one predictive model that predicts the likelihood that a treatment plan will cause a beneficial outcome for a particular patient. The predictive model may be validated, for example, by inputting data into the model and comparing the output of the model to an expected output.

[0057] In some embodiments, the treatment planning module 118 is configured to generate a treatment plan based on previous treatment data from a reference patient. For example, the treatment planning module 118 can receive a selected subset of the reference patient dataset and / or similar patient dataset from the data analysis module 116 and determine or identify treatment data from the selected subset. The treatment data can include, for example, treatment procedure data (e.g., surgical procedure or intervention data) and / or medical device design data (e.g., implant design data) associated with a beneficial or desired treatment outcome of the corresponding patient. The treatment planning module 118 can analyze the treatment procedure data and / or medical device design data and determine an optimal treatment protocol for treating the patient. For example, the treatment procedure and / or medical device design can be assigned a value and aggregated to generate a treatment score. A treatment plan specific to the patient can be determined by selecting a treatment plan based on this score (e.g., a higher or highest score, a lower or lowest score, a score that is higher, lower, or at a specified threshold). The personalized patient-specific treatment plan can be based at least in part on a patient-specific technique or a patient-specific selected technique.

[0058] Alternatively, or in combination, the treatment planning module 118 can generate a treatment plan based on correlations between the data sets. For example, the treatment planning module 118 can correlate treatment procedure data and / or medical device design data from similar patients with beneficial outcomes (e.g., as identified by the data analysis module 116). The correlation analysis can include converting the correlation coefficient values ​​into values ​​or scores. These values / scores can be aggregated, filtered, or otherwise analyzed to determine one or more statistical significances. These correlations can be used to determine treatment procedures and / or medical device designs that are optimal for treating the patient or likely to cause beneficial outcomes.

[0059] Alternatively, or in combination, the treatment planning module 118 can generate the treatment plan using one or more AI techniques. AI techniques can be used to develop computing systems that can simulate aspects of human intelligence, such as learning, reasoning, planning, problem solving, decision making, etc. AI techniques can include, but are not limited to, case-based reasoning, rule-based systems, artificial neural networks, decision trees, support vector machines, regression analysis, Bayesian networks (e.g., naive Bayes classifiers), genetic algorithms, cellular automata, fuzzy logic systems, multi-agent systems, swarm intelligence, data mining, machine learning (e.g., supervised learning, unsupervised learning, reinforcement learning), and hybrid systems.

[0060] In some embodiments, the treatment planning module 118 generates a treatment plan using one or more trained machine learning models. A wide variety of machine learning models, algorithms, and techniques are suitable for use with the present technology. In some embodiments, the machine learning model is first trained on a training dataset, which is a set of examples used to fit the model's parameters (e.g., weights of the connections between "neurons" in an artificial neural network). For example, the training dataset may include any of the reference data stored in the database 110, such as multiple reference patient datasets or a selected subset thereof (e.g., multiple similar patient datasets).

[0061] In some embodiments, a machine learning model (e.g., a neural network or a naive Bayes classifier) ​​may be trained on a training dataset using a supervised learning method (e.g., gradient descent or stochastic gradient descent). The training dataset may include pairs of generated "input vectors" with associated corresponding "answer vectors" (commonly denoted as targets). The current model is run using the training dataset to generate results, which are then compared to the targets for each input vector in the training dataset. Based on the results of the comparison and the particular learning algorithm being used, the parameters of the model are adjusted. Fitting the model may include both variable selection and parameter estimation. The fitted model may be used to predict responses to observations in a second dataset, called a validation dataset. The validation dataset may provide an unbiased assessment of the fit of the model to the training dataset while adjusting the model parameters. The validation dataset may be used for regularization by stopping early, for example, by stopping training early when the error on the validation dataset increases, as this may be a sign of overfitting to the training dataset. In some embodiments, the error of the validation data set is allowed to vary during training so that ad-hoc rules can be used to determine when overfitting has truly set in. Finally, a test data set can be used to provide an unbiased assessment of the fit of the final model to the training data set.

[0062] To generate a treatment plan, the patient dataset 108 may be input into the trained machine learning model. Additional data, such as a selected subset of the reference patient dataset and / or similar patient datasets, and / or treatment data from the selected subset, may also be input into the trained machine learning model. The trained machine learning model may then calculate whether various candidate treatment procedures and / or medical device designs are likely to cause beneficial outcomes for the patient. Based on these calculations, the trained machine learning model may select at least one treatment plan for the patient. In embodiments where multiple trained machine learning models are used, the models may be run sequentially or simultaneously to compare results and may be periodically updated using the training dataset. The treatment planning module 118 may use one or more of the machine learning models based on the predicted accuracy scores of the models.

[0063] The patient-specific treatment plan generated by the treatment planning module 118 may include at least one patient-specific therapeutic procedure (e.g., a surgical procedure or intervention) and / or at least one patient-specific medical device (e.g., an implant or implant delivery instrument). The patient-specific treatment plan may include an entire surgical procedure or a portion thereof. Additionally, one or more patient-specific medical devices may be selected or designed specifically for a corresponding surgical procedure, thus allowing various components of the patient-specific technology to be used in combination to treat the patient.

[0064] In some embodiments, the patient-specific therapeutic procedure includes an orthopedic procedure, such as spine surgery, hip surgery, knee surgery, jaw surgery, hand surgery, shoulder surgery, elbow surgery, total joint reconstruction (arthroplasty), skull reconstruction, foot surgery, or ankle surgery. Spinal surgery can include spinal fusion procedures, such as posterior lumbar interbody fusion (PLIF), anterior lumbar interbody fusion (ALIF), transverse or transforaminal lumbar interbody fusion (TLIF), lateral lumbar interbody fusion (LLIF), direct lateral lumbar interbody fusion (DLIF), or extreme lateral lumbar interbody fusion (XLIF). In some embodiments, the patient-specific therapeutic procedure includes instructions for and / or instructions for performing one or more aspects of a patient-specific surgical procedure. For example, the patient-specific surgical procedure may include one or more of a surgical technique, a corrective operation, a bone resection, or an implant placement.

[0065] In some embodiments, the patient-specific medical device design includes the design of an orthopedic implant and / or the design of an instrument for delivering the orthopedic implant. Examples of such implants include, but are not limited to, screws (e.g., bone screws, spinal screws, pedicle screws, facet screws), interbody implant devices (e.g., interbody implants), cages, plates, discs, fusion devices, spacers, rods, expandable devices, stents, brackets, ties, scaffolds, fixation devices, anchors, nuts, bolts, rivets, connectors, tethers, fasteners, joint replacements, hip implants, etc. Examples of instruments include, but are not limited to, screw guides, cannulas, ports, catheters, insertion tools, etc.

[0066] A patient-specific medical device design may include data representing one or more of the physical properties (e.g., size, shape, volume, material, mass, weight), mechanical properties (e.g., stiffness, strength, modulus, hardness), and / or biological properties (e.g., osteointegration, cell adhesion, antibacterial properties, antiviral properties) of a corresponding medical device. For example, an orthopedic implant design may include the shape, size, material, and / or effective stiffness (e.g., lattice density, number of struts, location of struts, etc.) of the implant. In some embodiments, the generated patient-specific medical device design is a design of the entire device. Alternatively, the generated design may be a design of one or more components of the device rather than the entire device.

[0067] In some embodiments, the design is of one or more patient-specific device components that can be used with standard off-the-shelf components. For example, in spinal surgery, a pedicle screw kit can include both standard components and patient-specific customized components. In some embodiments, the generated design is of a patient-specific medical device that can be used with standard off-the-shelf delivery instruments. For example, the implants (e.g., screws, screw holders, rods) can be designed and manufactured for the patient, but the instruments for delivering the implants can be standard instruments. This approach allows the components to be implanted to be designed and manufactured based on the patient's anatomy and / or surgeon's preferences to improve treatment. The patient-specific devices described herein are expected to improve delivery into the patient's body, placement at the treatment site, and / or interaction with the patient's anatomy.

[0068] In embodiments where the patient-specific treatment plan includes a surgical procedure to implant a medical device, the treatment planning module 118 may also store various types of implant surgery information, such as implant parameters (e.g., type, size), implant availability, pre-operative planning aspects (e.g., initial implant configuration, detection, and measurements of the patient's anatomy, etc.), FDA requirements for the implant (e.g., specific implant parameters and / or characteristics for compliance with FDA regulations). In some embodiments, the treatment planning module 118 may convert the implant surgery information into a format that can be used for machine learning based models and algorithms. For example, the implant surgery information can be tagged with a specific identifier for a formula or converted into a numerical representation suitable for feeding into a trained machine learning model. The treatment planning module 118 may also store information about the patient's anatomy, such as two-dimensional or three-dimensional images or models of the anatomy, and / or information about the biology, shape, and / or mechanical properties of the anatomy. The anatomy information may be used to inform the design and / or placement of the implant.

[0069] The treatment plan generated by the treatment planning module 118 may be transmitted to the digital filing cabinet 180 and / or the client computing device 102 via the communication network 104 for output to a user (e.g., a clinician, a surgeon, a healthcare provider, a patient). In some embodiments, the client computing device 102 includes or is operably coupled to a display for outputting the treatment plan. The display may include a graphical user interface (GUI) for visually illustrating various aspects of the treatment plan. For example, the display may display various aspects of a surgical procedure to be performed on a patient, such as a surgical technique, treatment levels, corrective operations, tissue resection, and / or implant placement. To facilitate visualization, a virtual model of the surgical procedure may be displayed. As another example, the display may display a design of a medical device to be implanted in the patient, such as a two-dimensional or three-dimensional model of the device design. The display may also display patient information, such as two-dimensional or three-dimensional images or models of the patient's anatomy on which the surgical procedure is to be performed and / or the patient's anatomy on which the device is to be implanted. The client computing device 102 may further include one or more user input devices (not shown) that enable a user to modify, select, accept, and / or reject the displayed treatment plan.

[0070] In some embodiments, the medical device design generated by the treatment planning module 118 may be transmitted from the client computing device 102 and / or the server 106 to a manufacturing system 124 to manufacture the implant or corresponding medical device. The manufacturing system 124 may be located on-site or off-site. The implant may be manufactured by any suitable manufacturing system (e.g., the manufacturing system 124 shown in FIG. 1). The digital filing cabinet 180 may store the generated medical device design, manufacturing data (e.g., CAM data, print data, etc.), manufacturing information, data for generating a surgical plan, a surgical plan, a surgical plan report, post-operative data (e.g., treatment plan, predicted outcome, etc.), and / or other information associated with the medical device.

[0071] Various types of manufacturing systems are suitable for use in accordance with embodiments herein. For example, the manufacturing system 124 may be configured for additive manufacturing, such as three-dimensional (3D) printing, stereolithography (SLA), digital light processing (DLP), fused deposition modeling (FDM), selective laser sintering (SLS), selective laser melting (SLM), selective heat sintering (SHM), electronic beam melting (EBM), laminated object manufacturing (LOM), powder bed printing (PP), thermoplastic printing, direct material deposition (DMD), inkjet photo-resin printing, or similar techniques, or combinations thereof. Alternatively, or in combination, the manufacturing system 124 may be configured for subtractive (conventional) manufacturing, such as CNC machining, electrical discharge machining (EDM), grinding, laser cutting, waterjet machining, manual machining (e.g., milling, lathe / turning), or similar techniques, or combinations thereof. The manufacturing system 124 may manufacture one or more patient-specific medical devices based on manufacturing instructions or data (e.g., CAD data, 3D data, digital blueprints, stereolithography data, or other data suitable for the various manufacturing techniques described herein). Various components of the system 100 may generate at least a portion of the manufacturing data used by the manufacturing system 124.The manufacturing data may include, but is not limited to, manufacturing instructions (e.g., programs executable by additive manufacturing equipment, subtractive manufacturing equipment, etc.), 3D data, CAD data (e.g., CAD files), CAM data (e.g., CAM files), path data (e.g., print head paths, tool paths, etc.), material data, tolerance data, surface finish data (e.g., surface roughness data), regulatory data (e.g., FDA requirements, reimbursement data, etc.), etc. The manufacturing system 124 may analyze the manufacturability of the implant design based on the received manufacturing data. The implant design may be finalized by modifying the shape, surface, etc., and then generating manufacturing instructions. In some embodiments, the server 106 generates at least a portion of the manufacturing data that is transmitted to the manufacturing system 124. The manufacturing system 124 may receive and transmit data using, for example, NFTs, ledgers, etc.

[0072] The manufacturing system 124 may generate CAM data, printing data (e.g., powder bed printing data, thermoplastic printing data, photo-resin data, etc.), and the like, and may include additive manufacturing equipment, subtractive manufacturing equipment, heat processing equipment, and the like. The additive manufacturing equipment may be a three-dimensional printer, a stereolithography device, a digital light processing device, a fused deposition modeling device, a selective laser sintering device, a selective laser melting device, an electron beam melting device, a laminated object manufacturing device, a powder bed printer, a thermoplastic printer, a direct material deposition device, or an inkjet photo-resin printer, or similar technology. The subtractive manufacturing equipment may be a CNC machine, an electrical discharge machine, a grinder, a laser cutter, a water jet machine, a manual machine (e.g., a milling machine, a lathe, etc.), or similar technology. Both additive and subtractive technologies may be used to manufacture implants having complex shapes, surface finishes, material properties, and the like. The generated manufacturing instructions may be configured to cause the manufacturing system 124 to manufacture a patient-specific orthopedic implant that matches or is therapeutically identical to the patient-specific design. The generated manufacturing instructions may be tokenized into a manufacturing NFT. In some embodiments, the patient-specific medical device may include features, materials, and designs that are shared across designs to simplify manufacturing. For example, deployable patient-specific medical devices for different patients may have similar internal deployment mechanisms but different deployed configurations. In some embodiments, components of the patient-specific medical device are selected from a set of available off-the-shelf components, and the selected off-the-shelf components may be modified based on the manufacturing instructions or data.

[0073] Following treatment of the patient according to the treatment plan, the progress of the treatment may be monitored over one or more time periods to update the data analysis module 116 and / or the treatment planning module 118. The post-treatment data may be added to the reference data stored in the database 110 and used for post-operative analysis. The post-treatment data may be used to train machine learning models to develop a patient-specific treatment plan, a patient-specific medical device, or a combination thereof.

[0074] It should be understood that the components of the system 100 may be configured in a variety of ways. For example, in an alternative embodiment, the database 110, the data analysis module 116, and / or the treatment planning module 118 may be components of the client computing device 102 rather than the server 106. As another example, the database 110, the data analysis module 116, and / or the treatment planning module 118 may be located across multiple different servers, computing systems, or other types of cloud computing resources rather than on a single server 106 or client computing device 102.

[0075] Additionally, in some embodiments, system 100 may be operable with numerous other computing system environments or configurations. Examples of computing systems, environments, and / or configurations that may be suitable for use with the present technology include, but are not limited to, personal computers, server computers, handheld or laptop devices, mobile phones, wearable electronics, tablet devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of these systems or devices, and the like.

[0076] 2 illustrates a computing device 200 suitable for use in connection with the system 100 of FIG. 1, according to an embodiment. The computing device 200 may be incorporated into various components of the system 100 of FIG. 1, such as the client computing device 102 or the server 106. The computing device 200 includes one or more processors 210 (e.g., CPU, GPU, HPU, etc.). The processor 210 can be a single processing unit or multiple processing units within one device or distributed across multiple devices. The processor 210 may be coupled to other hardware devices using a bus, such as, for example, a PCI bus or a SCSI bus. The processor 210 may be configured to execute one or more computer-readable program instructions, such as program instructions for performing any of the methods described herein.

[0077] Computing device 200 may include one or more input devices 220 that provide input to processor 210, for example, to inform processor 210 of actions from a user of device 200. These actions may be mediated by a hardware controller that interprets signals received from the input devices and communicates this information to processor 210 using a communication protocol. Input devices 220 may include, for example, a mouse, a keyboard, a touch screen, an infrared sensor, a touch pad, a wearable input device, a camera or image-based input device, a microphone, or other user input device.

[0078] The computing device 200 may include a display 230 used to display various types of output, such as text, models, virtual procedures, surgical plans, implants, graphics, and / or images (e.g., images including voxels showing radiodensity units or Hounsfield units representing tissue density at a location). In some embodiments, the display 230 provides graphical and textual visual feedback to the user. The processor 210 may communicate with the display 230 via a hardware controller of the device. In some embodiments, the display 230 includes the input device 220 as part of the display 230, such as when the input device 220 includes a touch screen or is equipped with a gaze direction monitoring system. In alternative embodiments, the display 230 is separate from the input device 220. Examples of display devices include an LCD display screen, an LED display screen, a projected display, a holographic display, or an augmented reality display (e.g., a head-up display device or a head-mounted device), etc.

[0079] Optionally, other I / O devices 240, such as a network card, a video card, an audio card, a USB, Firewire or other external device, a camera, a printer, speakers, a CD-ROM drive, a DVD drive, a disk drive, or a Blu-ray device, may also be coupled to the processor 210. The other I / O devices 240 may also include input ports for information from directly connected medical equipment, such as imaging devices including MRI machines, X-ray machines, CT machines, etc. The other I / O devices 240 may further include input ports for receiving data from these types of machines from other sources, such as over a network, or from previously captured data stored, for example, in a database.

[0080] In some embodiments, computing device 200 also includes a communication device (not shown) that can communicate wirelessly or based on wires with network nodes. The communication device can communicate with another device or server over a network, for example using TCP / IP protocols. Computing device 200 can utilize the communication device to distribute operations across multiple network devices, including imaging equipment, manufacturing equipment, etc.

[0081] The computing device 200 may include memory 250, which may be in a single device or distributed across multiple devices. The memory 250 may include one or more of various hardware devices for volatile and non-volatile storage, and may include both read-only and writeable memory. For example, the memory may include random access memory (RAM), various caches, CPU registers, read-only memory (ROM), and writeable non-volatile memory, such as flash memory, hard drives, floppy disks, CDs, DVDs, magnetic storage devices, tape drives, device buffers, and the like. Memory is not a signal that propagates separate from the underlying hardware, and thus memory is non-transient. In some embodiments, the memory 250 is a non-transient computer-readable storage medium that stores, for example, programs, software, data, and the like. In some embodiments, the memory 250 may include program memory 260, which stores programs and software, such as an operating system 262, one or more medical data modules 264, and other application programs 266. The medical data module 264 may include one or more modules configured to perform various methods described herein (e.g., the data analysis module 116 and / or the treatment planning module 118 described with respect to FIG. 1). The memory 250 may also include a data memory 270 that may include, for example, reference data, configuration data, settings, user options or preferences, etc., that may be provided in the program memory 260 or any other element of the computing device 200.

[0082] 3 is a system diagram illustrating an example computing environment in which the disclosed system operates in some embodiments. In some embodiments, the environment 300 includes one or more client computing devices 305A-D, examples of which may host device 200. The client computing devices 305 operate within a networked environment using logical connections with one or more remote computers, such as a server computing device, via a network 330. In some implementations, the client computing devices 305 may also include a medical implant, such as the medical implant 150 described above in connection with FIG. 1.

[0083] In some embodiments, device 310 is an edge server that receives client requests and coordinates fulfillment of those requests via other servers, such as servers 320A-C. In some embodiments, server computing devices 310 and 320 comprise computing systems, such as device 200. Although each server computing device 310 and 320 is logically viewed as a single server, each server computing device can be a distributed computing environment encompassing multiple computing devices located at the same physical location or at completely different geographical physical locations. In some embodiments, each server computing device 320 corresponds to a group of servers.

[0084] The client computing device 305 and the server computing devices 310 and 320 function as servers or clients to other servers or client devices, respectively. In some embodiments, the servers (310, 320A-C) connect to corresponding databases (315, 325A-C). As previously mentioned, each server 320 can correspond to a group of servers, each of which can share a database or have its own database. The databases 315 and 325 store (e.g., store) information such as medical information, health records, biometric information of users, blockchain transactions involving users' medical records, and other data. In some embodiments, the servers 320A-C can include digital filing cabinets and / or features of other servers disclosed herein, such as the server 106 of FIG. 1. Although the databases 315 and 325 are logically viewed as a single unit, the databases 315 and 325 can each be a distributed computing environment encompassing multiple computing devices, can be located within their corresponding servers, or can be located in the same physical location or in completely different physical locations geographically.

[0085] The network 330 can be a local area network (LAN) or a wide area network (WAN), but can also be other wired or wireless networks. In some embodiments, the network 330 is the Internet or some other public or private network. The client computing devices 305 are connected to the network 330 through a network interface, such as by wired or wireless communications. Although the connections between the server 310 and the server 320 are shown as separate connections, these connections can be any type of local area network, wide area network, wired network, or wireless network, including the network 330 or separate public or private networks.

[0086] FIG. 4 is a block diagram illustrating components 400 that may be used in a system employing the disclosed technology in some implementations. The components 400 may be used to store, manage, analyze, and access medical data in a digital filing cabinet. The components 400 include hardware 402, general software 420, and specialized components 440. As previously mentioned, a system implementing the disclosed technology may use a variety of hardware, including a processing unit 404 (e.g., CPU, GPU, APU, etc.), a working memory 406, a storage memory 408 (as local storage or an interface to remote storage such as storage 315 or 325), and input and output devices 410. In various implementations, the storage memory 408 may be one or more of a local device, an interface to a remote storage device, or a combination thereof. For example, storage memory 408 can be a set of one or more hard drives (e.g., redundant array of independent disks (RAID)) accessible via a system bus, or can be a cloud storage provider or other network storage (e.g., a network accessible storage (NAS) device, such as storage 315 or storage provided via another server 320) accessible via one or more communications networks. Component 400 can be implemented within a client computing device, such as client computing device 305, or on a server computing device, such as server computing device 310 or 320.

[0087] The general software 420 can include various applications, including an operating system 422, a local program 424, and a basic input-output system (BIOS) 426. The specialized components 440 can be subcomponents of the general software applications 420, such as the local program 424. The specialized components 440 can be for providing patient-specific medical data and can include an authentication module 444, an EMR module 446, an account linking module 448, a patient treatment data module 450, an integration module 452, a post-op analysis module 454, a machine learning module 456, a control module 458, a point-of-care module 460, an NFT module 462, a cryptography module 464, and components that can be used to provide a user interface, transfer data, and control the specialized components, such as an interface 442 (e.g., a user interface on a tablet, a smartphone, a laptop, etc.). In some implementations, the components 400 can be in a computing system that is distributed across multiple computing devices or can be an interface to a server-based application that executes one or more of the specialized components 440. The particular components 440, although shown as separate components, may be logical or other non-physical distinctions of functionality and / or may be sub-modules or code blocks of one or more applications.

[0088] The authentication module 444 provides authenticated management of patient-specific medical data to users (e.g., patients, family members, healthcare providers, authorized users, etc.). The authentication module 444 can manage access privileges (e.g., read-only, ability to edit, privacy protection, etc.) to the medical data based on geographic location, biometrics, blockchain, tokens (e.g., NFTs), or key functions for user authentication. The authentication module 444 provides a token function for user authentication to access medical data. The authentication module 444 can generate a token for a user to access medical records. In some implementations, the token is valid for a threshold of time during which the user can access the medical records. A user can request a token from the authentication module 444 and receive a token from the authentication module 444. In some implementations, the authentication module 444 provides a key function for user authentication to access medical data. The authentication module 444 can share an authentication key (e.g., a symmetric key or an asymmetric key) with the user over a secure channel for the user to access the medical data during authentication.

[0089] The authentication module 444 provides biometric functionality for user authentication to access medical data. A user can provide their biometric information (e.g., voice, face scan, fingerprint, iris scan, dental records, height, weight, etc.) to the authentication module 444. The authentication module 444 can store the biometric information. When a user attempts to access medical data, the authentication module 444 can verify the user's identity based on the biometric information before granting the user access to the medical records. In some cases, the authentication module 444 requires the user to provide two or more types of biometric information, such as a fingerprint and a voice, before granting the user access to the medical records.

[0090] The authentication module 444 provides geolocation functionality for user authentication to access medical data. The authentication module 444 can verify the location of the user device or the location of the patient device attempting to access medical data when determining to allow the user to access medical data. In one example, a medical provider can access a patient's medical records only at a medical facility. In another example, a medical provider can access a patient's medical records only if the patient is at the medical provider's medical facility.

[0091] The authentication module 444 provides blockchain functionality for user authentication to access medical data. The authentication module 444 allows for the creation of new blocks in new / existing blockchain distributed ledgers, hashing of new blocks, and adding new blocks to the patient's private blockchain and distributed ledgers. The authentication module 444 can manage multiple public blockchains, private blockchains, and / or other distributed ledgers for patients. In some implementations, privacy of each patient's blockchain can be guaranteed since each patient maintains a separate blockchain and / or ledger for the patient's medical records and data. In other implementations, the transaction includes a public key that matches a private key associated with the patient. In these implementations, while the transaction is added to the public ledger, transaction details can only be accessed if the private key is used, ensuring patient data confidentiality.

[0092] New blocks of the blockchain and / or ledger are based on the received medical data. In some implementations, the created blockchain ledger may be stored in a persistent memory of the patient's implant. In other implementations, the created blockchain ledger may be stored in a memory associated with the system and may be a private blockchain ledger associated exclusively with the patient or a public blockchain ledger associated with a group of patients. If the blockchain ledger is a public ledger, each block may be associated with a different patient, but may not be accessible for viewing unless a medical professional possesses the private key associated with the patient identified in a particular block in the ledger. Patient groups may be subdivided in multiple ways. For example, patient groups may be defined as all patients at a particular medical facility, all patients receiving treatment from a particular medical professional, all patients covered by a particular medical insurance company, all patients with similar medical conditions, treatments, outcomes, etc.

[0093] The NFT module 462 can convert the medical data into one or more NFTs on the blockchain. In some implementations, the medical data is converted into multiple NFTs based on the type of data (e.g., medical images, billing information, post-surgery information, implant information, biometric information, surgery details, personal identifiable information (PII), etc.), and the multiple NFTs are bundled into a single NFT. In some embodiments, the NFT module 462 can analyze the data, identify data based on one or more rules, group the identified data, and convert the grouped data into an NFT. For example, the NFT module 462 can identify patient imaging data or exams, charts or information, surgery information, etc. The NFT module 462 can then (1) convert the patient imaging data or exams into one or more imaging exam NFTs, (2) convert the patient information into one or more patient information NFTs, (3) convert the surgery information into one or more surgery NFTs, etc. For example, the NFT module 462 can generate specific surgical procedure NFTs that contain information about each surgical procedure. The information included in or associated with the NFT may be selected by a user. The NFT module 462 may also include a machine learning engine trained to identify, classify, group, and / or convert data into an NFT. For example, a machine learning model may be trained using medical datasets such as an imaging exam dataset, an EMR dataset, a patient information dataset, a surgery information dataset, etc. The machine learning engine may then group the data to be included in or linked to the NFT.

[0094] The NFTs may be bundled into one bundling NFT. The bundling NFT may include, for example, one or more imaging exam NFTs, patient information NFTs, surgery NFTs, etc. The type and number of NFTs included in the bundling NFT may be selected by the patient, healthcare provider, etc. In some embodiments, the NFT may be containerized in the NFT itself and hold EMR, image data, scans, or other medical data disclosed herein. In some embodiments, the NFT is linked to medical data stored outside the blockchain, for example, using a decentralized or centralized storage network. The medical data may be used to generate metadata for the NFT.

[0095] The NFT module 462 can generate non-transferable and transferable NFTs. Non-transferable NFTs improve security of medical data based on blockchain properties. For example, NFTs provide validation of digital medical data (e.g., authenticating credentials, data integrity, maintaining a source of truth for patient health records, etc.), ownership of medical data, portability of medical data, patient-specific solutions based on verifiable patient data, patient-specific algorithms for treatment, patient-selectable sharing of medical data, traceable use of patient data, economic value (e.g., anonymized, identified, aggregated, segmented, parsed, grouped, etc.) related to the use of medical data. The NFT module 462 can create transferable NFTs with rules (e.g., smart contracts) that control how the NFT is used. For example, the NFT can include expiration dates, instructions, require verification of the intended recipient, instructions for implant treatment (by surgical robots), traceable chain of custody (supply chain), authenticity (elimination of counterfeit products), and / or payment (repayment) for a (verified and traceable) product in cryptocurrency. The NFT module 462 can select or create a smart contract based on user input, type of medical data, or other criteria. The NFT module 462 can create a digital key for the user, such as a private key to allow access to the medical data. In some implementations, a digital filing cabinet is a repository of NFTs and digital keys (public and private keys). Medical data transactions (e.g., access, transmission, receipt, etc.) can be captured, tracked, and / or authenticated using NFTs. By converting medical data into NFTs, each transaction of medical data becomes fully portable, traceable, secured, and authorized.

[0096] The authentication module 444 can authenticate the user using multi-factor identification, such as requiring two types of authentication from an authentication group including blockchain, biometric, token, key, and geographic location types of authentication. The authentication module 444 can adjust the authentication requirements based on the user's health metrics. For example, if the user's heart rate is below a threshold level (e.g., indicating the user is experiencing a medical emergency), the authentication module 444 requires a lower level of authentication by a medical provider to access the patient's medical record. By adjusting the level of authentication, the medical provider (e.g., surgeon, EMT, etc.) can access the medical information while treating the user during the medical emergency. The authentication module 444 can require different levels of security based on the type of medical information in the medical record. For example, health metrics such as blood pressure or heart rate from a wearable device require a lower level of authentication to be accessed than the patient's health history or medical insurance information.

[0097] The EMR module 446 maintains the patient's electronic medical record. The EMR may include patient medical data (e.g., images, scans, documents, etc.), demographic information about the patient, patient identification information, past patient treatment data, indicators, plans (e.g., pre-op plans, revision plans, operative plans, post-op plans, etc.), data providing information related to the medical condition, provider information (e.g., physician, hospital, surgical team, etc.), patient feedback (e.g., feedback obtained using quality of life questionnaires, surveys, patient-reported outcome measures, etc.), vital signs, diagnostic results, and / or other medically relevant information about the patient such as family history of various diseases or medical problems, prescription drug history, etc. The EMR module 446 may also maintain patient treatment records such as medical procedures received, implant information (e.g., patient-specific design, composition, implant treatment date, manufacturer, etc.), drug treatments performed, clinical trials participated in, and other related medical procedures performed for the patient's health. Each medical procedure may also include various additional data points such as the attending physician, prescribing physician, date and time of the procedure, the patient's medical response, the medical procedure performed, and other related medical data points. In some implementations, the EMR may also include various related images and scans (e.g., CT scans, 3D CT scans, CMCT scans, MRIs, PET scans, etc.), images associated with medical procedures such as medical images (e.g., X-ray images, magnetic resonance imaging, ultrasound images, etc.), blood test results, etc. The EMR module 446 can provide the EMR to the authentication module 444 to generate transactions based on the EMR. The EMR module 446 manages the user's medical records, such as implant data, surgery plans, health records, or medical insurance information. The EMR module 446 can detect updates regarding the user's medical record and implement updates to the medical record. For example, the EMR module 446 can detect that a family member has been added to a medical insurance plan and update the medical record to include the additional family member.

[0098] The account linking module 448 links accounts between healthcare providers, family members, bank accounts, credit card accounts, insurance companies, government agencies, or any accounts that provide information to an implant (user account), a medical analytics cloud, a digital filing cabinet, or a healthcare provider. A user (e.g., a patient or healthcare provider) can provide account credentials (e.g., username, password, pin, etc.) to the account linking module 448. In some implementations, the account linking module 448 identifies accounts that the user needs to provide, such as insurance accounts, medical history accounts, or payment accounts, so the system can provide services to the user.

[0099] The patient care data module 450 collects patient data regarding medical events or actions (e.g., hospitalizations, medical procedures, drug treatment plans, etc.) from various medical systems. In one example, the patient care data module 450 can receive identification information identifying the patient, results from a routine doctor's visit, and any relevant data associated with this visit, such as various medical images taken, blood pressure values, heart rate, blood oxygen levels, body mass index, and / or other medical data. The patient care data module 450 can provide this data in the EMR to the EMR module 444 to create a new EMR for the patient.

[0100] The integration module 452 integrates input sources of patient medical data. The input sources may include a medical data digital filing cabinet, a digital wallet, a wearable device, a patient implant, a health insurance company device, a medical provider device, a cloud-based analytics device, or a patient device. In some implementations, the integration module 452 identifies new medical data (e.g., medical records, medical images, health goals, medical diagnoses, etc.) that are added to the digital filing cabinet and updates the organized medical data with the new medical data.

[0101] The post-op analysis module 454 collects and analyzes patient information, patient goals, provider goals for the patient, medical procedure results, health indicator goals (e.g., BMI, blood pressure, etc.), provider notes from the procedure or patient exam, etc. For example, after a medical procedure, the post-op analysis module 454 analyzed x-ray images to determine if the medical procedure was successful. The post-op analysis module 454 can determine if the patient should participate in physical therapy based on collected health indicators such as the patient's mobility (e.g., range of motion of the limbs or fingers). The post-op analysis module 454 can identify EMRs that the provider should review, such as new locations in an MRI that may indicate cancer. In some implementations, the post-op analysis is converted into an NFT.

[0102] The machine learning module 456 may be configured to analyze the user's medical data in the digital filing cabinet and determine to notify an event (e.g., emergency, appointment, health goal, etc.). The machine learning module 456 may be configured to analyze the medical data based on at least one machine learning algorithm trained on at least one dataset reflecting the user's medical information, goals, and health status. The at least one machine learning algorithm (and model) may be stored locally in the database and / or outside the database (e.g., in a cloud database and / or cloud server). The client device may be equipped to access these machine learning algorithms, intelligently analyze the medical data, and notify the user based on at least one machine learning model trained on the user's past medical data. For example, if the user's blood glucose level frequently rises, the user's health indicators may be collected to train a machine learning model and then automatically notify the user to exercise to help lower the user's blood glucose level.

[0103] As described herein, a machine-learning (ML) model may refer to a predictive or statistical utility or program that may be used to determine a probability distribution over one or more character sequences, classes, objects, outcome sets, or events, and / or predict a response value from one or more predictors. The model may be based on or incorporate one or more rule sets, machine learning, neural networks, and the like. In an example, the ML model may be located on a client device, a service device, a network appliance (e.g., a firewall, a router, etc.), or some combination thereof. The ML model may process a user's medical data and other data stores of the user's health indicators and determine when to generate a notification to the user. Based on the aggregation of data from a user's medical digital filing cabinet, wearable devices, and other user data stores, at least one ML model may be trained and then deployed to automatically generate medical notifications. The trained ML model may be deployed to one or more devices. As a specific example, an instance of the trained ML model may be deployed to a server device and to a client device. The ML model deployed on the server device may be configured to be used by the client device, for example, when the client device is connected to the Internet. Conversely, the ML model deployed on the client device may be configured to be used by the client device, for example, when the client device is not connected to the Internet. In some examples, the client device may not be connected to the Internet but still be configured to receive satellite signals that include the medical data. In such examples, the ML model may be cached locally by the client device. In some implementations, the machine learning module 456 identifies new medical data in the digital filing cabinet and updates the patient's health goals or health indicators based on the new medical data.

[0104] The control module 458 controls the patient medical data in the healthcare provider digital filing cabinet. The control module 458 can determine automated settings to periodically or continuously search for additional data to add to the digital filing cabinet. The control module 458 can manage the privacy of the medical data of any user attempting to access the patient medical data by requiring authentication information (as described in authentication module 444). In some implementations, the control module 458 encrypts the patient medical data. The control module 458 can identify new medical data and update the healthcare provider's digital filing cabinet to include the new medical data.

[0105] The Point of Care (POC) module 460 identifies POC devices, such as provider devices (e.g., medical instruments, charting devices, patient monitoring devices, etc.) or patient devices (e.g., wearable devices, implants, smartphones, etc.), and retrieves data collected from the POC devices. The POC module 460 can collect health history data, treatment data, patient health metrics, patient geographic location, insurance information, biometric data, or payment information from the POC devices. The POC module 460 can display a version of the health data on the user device for the provider to show to the patient. For example, the POC module 460 displays an X-ray image in a user interface so the patient can see the implant after a surgical procedure. The POC module 460 provides alerts based on events identified from the medical data entered into the digital filing cabinet. For example, an alert is a notification to a user (e.g., a physician, a doctor, a patient, etc.) from monitoring the data collected from the wearable device. The POC module 460 can generate alerts requesting additional or updated patient information, scheduling an appointment, notifying of an emergency, etc. For example, the POC module 460 can generate an alert if a patient's health indicators (e.g., heart rate, blood pressure, temperature, etc.) fall outside of health indicator thresholds (e.g., thresholds or ranges determined by a healthcare provider).

[0106] The crypto module 464 can charge cryptocurrency for each NFT transaction. Examples of transactions (or transaction steps) may include imaging (e.g., MRI imaging, x-ray imaging, radiology imaging) converted to an NFT, patient information (e.g., height, weight, gender, health status, etc.) converted to an NFT, surgery details (e.g., surgery date, surgical team, instrument information, implant information, doctor information, etc.) converted to an NFT, bundling of NFTs, sending an NFT to a recipient for surgical planning, creating a surgical plan with an NFT, sending a surgical plan NFT to a healthcare provider (e.g., doctor, hospital, clinic, surgeon, etc.), sending a plan approval using an NFT, creating an implant design with an NFT, sending an implant design NFT to a manufacturing company, manufacturing an implant based on the implant design NFT, shipping a physical implant to an operating room, post-operative data being collected and converted to an NFT, and / or sending a post-operative data NFT to a recipient for incorporation into feedback for subsequent corrections and implant designs. The NFT may include lockable content (e.g., patient medical data), non-lockable content (e.g., contact information for a medical provider), etc. The crypto module 464 may create crypto coins for transactions of NFTs of medical data. The NFTs, crypto coins, and digital keys may be stored in a digital wallet.

[0107] FIG. 5 is a flow diagram illustrating a process 500 for converting patient-specific medical data into a non-fungible token, according to an embodiment. At step 502, the process 500 can receive medical data from multiple entities (e.g., a healthcare provider, a hospital, a clinic, an insurance company, a patient's social media account, a patient, etc.) and store the medical data in a digital filing cabinet. In some implementations, the digital filing cabinet resides in an implant (e.g., a blockchain-enabled medical implant) in the patient. In some implementations, the digital filing cabinet is located on a cloud-based device, a storage device, a healthcare provider's device, and / or a patient's device. The patient can provide account credentials (e.g., username, password, etc.) that provide data to the digital filing cabinet. The medical data (e.g., EMR) can include data representing a patient's condition, anatomy, medical condition, symptoms, medical history, preferences, implant information, and / or any other information or parameters related to the patient. For example, medical data can include surgical intervention data, treatment outcome data, progress data (e.g., surgeon's notes), patient feedback (e.g., quality of life questionnaires, feedback obtained using surveys), clinical data, patient information (e.g., demographics, gender, age, height, weight, type of medical condition, occupation, activity level, organizational information, health assessment, comorbidities, health-related quality of life (HRQL)), vital signs, diagnosis results, medication information, allergies, diagnostic equipment information (e.g., manufacturer, model number, specifications, settings / configuration selected by the user, etc.) Medical data can also include image data, such as camera images, magnetic resonance imaging (MRI) images, ultrasound images, computer-aided tomography (CAT) scan images, positron emission tomography (PET) images, x-ray images, etc. In some embodiments, the medical data includes data representing one or more of a patient identification number (ID), age, sex, body mass index (BMI), lumbar lordosis, Cobb angle, pelvic intrinsic angle, disc height, segmental flexibility, bone quality, rotational displacement, and / or spinal treatment level.The medical data may include implant information (e.g., dimensions, materials, design, etc.) regarding the patient's implant. The medical data may be received at a server, computing device, or other computing system. For example, in some embodiments, the patient data set may be received by the server 106 shown in FIG. 1. The computing system that receives the medical data in step 502 may also store one or more software modules (e.g., the data analysis module 116 shown in FIG. 1 or additional software modules for performing various operations of process 500).

[0108] At step 504, the process 500 converts the medical data into NFTs. The process 500 can generate digital keys (private and public) to access each NFT and a digital wallet. A user can "unlock" the NFT using the digital key. The digital wallet can be a repository of NFTs, crypto coins, and digital keys. The process 500 can issue the digital wallet and key to the user. In one example, the process 500 issues a digital wallet to a patient that includes a private key to allow access to the medical data in the NFT. In another example, the process 500 issues a digital wallet to a hospital that includes a public key to allow access to the medical data in the NFT. In another example, the process 500 issues a digital wallet to a surgeon that includes a public key to allow access to the medical data in the NFT and a private key to allow the surgeon specific access to the medical data in the NFT. In some embodiments, the process 500 tokenizes the medical data into an NFT by determining a storage location of the medical data and generating an NFT linked to the medical data. The type of link (e.g., URL, Interplanetary File System link, etc.) may be selected based on the time frame and cost of storage. The NFT may include metadata along with the link, allowing medical data or links to be moved along with the NFT.

[0109] At step 506, the process 500 generates access parameters (e.g., smart contract, authentication level from authentication module 444 of FIG. 4, etc.) for each NFT. For example, the access parameters may limit the number of times the NFT may be accessed by a user (e.g., one-time use, a threshold number of times, etc.). In some implementations, the NFT has an expiration date, and the user may only access the NFT before the expiration date. For example, if an NFT of a patient's implant design is sent to a manufacturer, the access parameters of the NFT may limit the manufacturer to viewing the implant design to a certain date before the NFT expires. The access parameters may protect the implant design by ensuring that the manufacturer is the only person who can access the NFT. The access parameters may include additional features, such as the user's geographic location, the user's device, biometrics, or other authentication information. For example, if a healthcare provider accesses an NFT containing patient medical data, the process 500 may require the healthcare provider to provide a digital key to verify that the healthcare provider is at the healthcare provider's location.

[0110] At step 508, process 500 manages access to the medical data associated with (e.g., linked to, part of, etc.) the NFT according to access parameters. The user may provide a digital key (public and / or private key) to access the medical data, and possibly biometric data, geolocation data, or other types of authentication data to access the medical data. At step 510, process 500 stores the NFT in a digital wallet. The digital wallet may be stored in a digital filing cabinet.

[0111] FIG. 6 is a flow diagram illustrating a process 600 for managing access to patient-specific medical data from an implant, according to an embodiment. The process 600 can establish communication contact with a blockchain-enabled medical implant by a device associated with a user using a proximity mode. A "proximity mode" can mean that the user device is within a distance of the implant such that the user device and the implant are on (or have access to) the same local area network, or such that the user device and the implant are paired using a short-range communication protocol, such as Bluetooth or Near Field Communication (NFC). For example, a user (e.g., a patient, a healthcare provider, etc.) can connect to the implant using a device via a communication link to access medical data stored on the implant.

[0112] At step 602, process 600 receives a request from a user (e.g., a patient, a medical provider, an insurance salesperson, an implant manufacturer, etc.) to access an NFT containing medical data. For example, the user may scan the patient's body implant or access the NFT via a blockchain network device. The user may provide authorization credentials (e.g., a password, a passphrase, a token, a security push code, etc.) to access the private key. Based on the patient's authorization credentials, process 600 may grant the user access to the private key stored in the blockchain-enabled medical implant.

[0113] At step 604, process 600 determines access parameters for the user's NFT. In some implementations, the user can access the medical data in the NFT using the digital key. In some implementations, process 600 requires the user to provide the digital key in addition to geographic location data, biometric data, or other authentication information before granting the user access to the medical data.

[0114] At step 606, the process 600 determines the amount of medical data to provide based on the user and the access parameters. The user is given read-only capability, editing capability, or the ability to view all or a portion of the medical data based on the user and the access parameters. For example, the patient can view all of the patient's own medical data and personal information (e.g., SSN, banking information, insurance information, etc.), while the medical provider is limited to the patient's health history information. In some implementations, the patient's location (e.g., determined via the location of the implant) can determine the access parameters of the NFT. For example, if the patient is in an accident abroad, the medical provider can only access emergency contact information or certain emergency medical information (e.g., blood type, allergies, medications, etc.) from the NFT. However, if the medical provider is the patient's primary medical provider (as verified by biometrics), this medical provider has a different level of access to the medical data than another medical provider.

[0115] The process 600 can access a private key stored in the blockchain-enabled medical implant based on the authentication level (e.g., access parameters) to access the patient-specific medical data in the NFT. The private key can be used to access the patient-specific medical data. In some implementations, the medical implant also includes a private blockchain ledger to track the EMR associated with the patient. As the patient undergoes various treatments, new and updates to the patient's existing EMR are generated and stored as "transactions" in the blockchain ledger. To access the EMR associated with the patient, the private key from the medical implant must be used to "unlock" the EMR stored in the blockchain ledger. The patient can provide this private key to the healthcare provider and other parties via a secure platform, mobile application, digital key, etc. In some embodiments, the EMR is encrypted using an encryption key that the healthcare provider decrypts. Additionally or alternatively, key change protocols, certificate management protocols (e.g., registration certificate protocol, transaction certificate protocol, etc.), and other protocols can be utilized for variable access and authorization. The patient can manage the data in the EMR to share only selected data. For example, a patient may be able to share one section of the EMR while keeping another section private. The system also allows for user-controlled settings, such as settings related to minors, family members, relatives, and / or settings controlled by other users.

[0116] At step 608, process 600 allows the user to access the medical data based on the access parameters of the NFT. The implant can include a wireless chip (e.g., a Bluetooth chip or a Near Field Communication (NFC) chip) so that the user interface can receive the medical data wirelessly. Process 600 can transmit the medical data in an encrypted format, and the user can decrypt the medical data. In some implementations, process 600 can generate and transmit a code (e.g., QR, RFID, etc.) that the user can scan to access the medical data on the implant. In some implementations, process 600 denies the user access to the NFT.

[0117] Systems / devices 100, 200, 300, 400 may perform one or more steps of the methods described in connection with Figures 5-6. For example, the systems and components may perform various steps and methods described in connection with Figures 5-6, among other steps and methods disclosed herein. Thus, although certain operations are described in connection with Figures 5-6 with respect to particular components, other components and systems disclosed herein may be incorporated into or operate in conjunction with other components disclosed herein.

[0118] 7 illustrates an example of a medical data set 700 (e.g., as received in step 502 of FIG. 5) that may be converted into an NFT. The medical data 700 may include any of the information previously described with respect to medical data. For example, the medical data may include patient information (e.g., patient identification number, patient MRN, patient name, sex, age, body mass index (BMI), date of surgery, surgeon, etc.), diagnostic information (e.g., Oswestry Disability Index (ODI), VAS back score, VAS leg score, pre-op pelvic intrinsic angle, pre-op lumbar lordosis, pre-op PI-LL angle, pre-op lumbar coronal cobb, etc.), and image data 702 (x-ray, CT, MRI, etc.).

[0119] FIG. 8 provides a series of images illustrating an example of a patient surgical plan report 800 that may be converted to an NFT and sent to the patient. The surgical plan report 800 may include an overview of the surgical plan, patient images, patient metrics, surgical details, and related information that the patient may view. The patient surgical plan report 800 may be presented to the patient on a digital display of a computing device (e.g., the client computing device 102 shown in FIG. 1). In some embodiments, the report 800 is interactive, and the patient may manipulate various aspects of the report 800 (e.g., adjust the view, zoom in, zoom out, annotate, etc.). The patient may provide questions or comments to the healthcare provider, which may be sent back to the computing system that generated the surgical plan report 800 for analysis and response.

[0120] As one skilled in the art would understand, any of the software modules previously described may be combined into a single software module to perform the operations described herein. Similarly, the software modules may be distributed across any combination of the computing systems and devices described herein and are not limited to the specific arrangements described herein. Thus, any of the operations described herein may be performed by any of the computing devices or systems described herein unless expressly stated otherwise.

[0121] The foregoing detailed description has illustrated various embodiments of devices and / or processes through the use of block diagrams, flow charts, and / or examples. To the extent that such block diagrams, flow charts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation included in such block diagrams, flow charts, or examples can be individually and / or collectively implemented by a wide range of hardware, software, firmware, or virtually any combination thereof. In some embodiments, portions of the subject matter described herein may be implemented by Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), or other integrated forms. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may equivalently be implemented, in whole or in part, in integrated circuits as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing circuitry and / or writing software and / or firmware code is well within the skill of those skilled in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the subject mechanisms described herein may be distributed as a program product in a variety of forms, and that example embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution.Examples of signal bearing media include, but are not limited to, recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.). EXAMPLES

[0122] The present technology is illustrated, for example, according to various aspects described below. Various embodiments of aspects of the technology are described as numbered embodiments (1, 2, 3, etc.) for convenience. These are provided as examples and do not limit the present technology. It is noted that any of the dependent embodiments may be combined and arranged in any suitable manner into each independent embodiment. Other embodiments may be presented in a similar manner. 1. A computer-implemented method for providing patient-specific medical data using a non-fungible token platform, the method comprising: receiving patient-specific medical data for the patient from at least one input data source; converting patient-specific medical data into at least one non-fungible token using a non-fungible token platform; storing at least one non-fungible token in a medical digital filing cabinet; managing access to the at least one non-fungible token based on at least one access parameter; receiving a request by a user to access patient-specific medical data in at least one non-fungible token; determining an amount of patient-specific medical data in the at least one non-fungible token to provide to a user based on an authentication level of the user and at least one access parameter; and transmitting the determined amount of the patient-specific medical data to a user interface of the user. 2. Patient-specific medical data is associated with a blockchain-enabled medical implant implanted in the patient's body, and the method: Establishing communication contact with the blockchain-enabled medical implant using a proximity mode of communication; and accessing a private key stored in the blockchain enabled medical implant based on the authentication level to access the patient-specific medical data in the at least one non-fungible token. 3. Access to the private key is receiving encoded data from a blockchain-enabled medical implant in the patient according to a proximity communication mode; 3. The computer-implemented method of any one of Examples 1-2, further comprising: deriving a private key based on decrypting the encoded data using the user's authorization authentication information. 4. The computer-implemented method of any of Examples 1-3, wherein the request includes providing a user's authorization authentication information using a verification mechanism, the verification mechanism being voice verification, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, providing biometric information, providing geographic location information, or providing an electronic signature to the physician. 5. Determining types of patient-specific medical data stored in at least one non-fungible token; and The computer-implemented method of any one of Examples 1 to 4, further comprising generating at least one access parameter based on the type of patient-specific medical data. 6. Creating a patient digital wallet; 6. The computer-implemented method of any of Examples 1-5, further comprising storing the private key and the public key of the at least one non-fungible token in the digital wallet. 7. The computer-implemented method of any of Examples 1-6, wherein each transaction of at least one non-fungible token is associated with an amount of cryptocurrency. 8. The computer-implemented method of any one of Examples 1-7, wherein the medical digital filing cabinet is part of a distributed ledger of a non-fungible token platform, the distributed ledger storing at least one non-fungible token containing patient-specific medical data. 9. The computer-implemented method of any of Examples 1-8, wherein the medical digital filing cabinet includes a digital patient NFT wallet owned by the patient. 10. A non-transitory computer readable medium storing instructions that, when executed by a computing system, cause the computing system to perform operations for providing patient-specific medical data from a blockchain-enabled medical implant implanted within a patient's body, the operations including: receiving patient-specific medical data from at least one input data source; Transforming patient-specific medical data into at least one non-fungible token; storing at least one non-fungible token in a medical digital filing cabinet; managing access to the at least one non-fungible token based on at least one access parameter; receiving a request by a user to access patient-specific medical data in at least one non-fungible token; determining an amount of patient-specific medical data in the at least one non-fungible token to provide to a user based on an authentication level of the user and at least one access parameter; and transmitting the determined amount of patient-specific medical data to a user interface of the user. 11. Blockchain-enabled medical implants will be implanted in patients’ bodies and will operate like this: Establishing communication contact using a proximity communication mode; and accessing a private key stored in the blockchain enabled medical implant based on the authentication level to access the patient-specific medical data in the at least one non-fungible token. 12. Access to private keys is receiving encoded data from the blockchain enabled medical implant according to a proximity communication mode; A non-transitory computer-readable medium according to any one of Examples 10 to 11, further comprising: deriving a private key based on decrypting the encoded data using the user's authorization authentication information. 13. A non-transitory computer-readable medium according to any of Examples 10 to 12, wherein the request includes providing a user's authorization authentication information using a verification mechanism, the verification mechanism being voice verification, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, providing biometric information, providing geographic location information, or providing an electronic signature to the physician. 14. Operation: determining types of patient-specific medical data stored in at least one non-fungible token; A non-transitory computer-readable medium according to any one of Examples 10 to 13, further comprising generating at least one access parameter based on a type of medical data specific to the patient. 15. Operation: Creating a patient digital wallet; The non-transitory computer-readable medium of any of Examples 10-14, further comprising storing a private key and a public key of at least one non-fungible token in a digital wallet. 16. The non-transitory computer-readable medium of any of Examples 10-15, wherein each transaction of at least one non-fungible token is associated with an amount of cryptocurrency. 17. One or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the system to perform a process for providing patient-specific medical data from a blockchain-enabled medical implant implanted within a patient, the process comprising: receiving patient-specific medical data from at least one input data source; Transforming patient-specific medical data into at least one non-fungible token; storing at least one non-fungible token in a medical digital filing cabinet; managing access to the at least one non-fungible token based on at least one access parameter; receiving a request by a user to access patient-specific medical data in at least one non-fungible token; determining an amount of patient-specific medical data in the at least one non-fungible token to provide to a user based on an authentication level of the user and at least one access parameter; and transmitting the determined amount of patient-specific medical data to a user interface of the user. 18. A blockchain-enabled medical implant is implanted in the patient’s body and the process Establishing communication contact using a proximity communication mode; 18. The system of example 17, further comprising: accessing a private key stored in the blockchain enabled medical implant based on the authentication level to access the patient-specific medical data in the at least one non-fungible token. 19. Access to private keys is receiving encoded data from the blockchain enabled medical implant according to a proximity communication mode; 19. The system of any one of Examples 17-18, further comprising: deriving a private key based on decrypting the encoded data using the user's authorization authentication information. 20. The process is determining types of patient-specific medical data stored in at least one non-fungible token; The system of Examples 17 to 19, further comprising generating at least one access parameter based on a type of medical data specific to the patient. 21. The process is Creating a patient digital wallet; The system of any one of Examples 17 to 20, further comprising storing a private key and a public key of at least one non-fungible token in the digital wallet. 22. The request includes providing user authorization credentials using a verification mechanism; the verification mechanism is voice verification, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, providing biometric information, providing geographic location information, or providing an electronic signature to the physician; 22. The system of embodiments 17-21, wherein each transaction of at least one non-fungible token is associated with an amount of cryptocurrency. 23. A computer-implemented method for providing patient-specific medical data to a patient using a non-fungible token platform, the method comprising: generating at least one digital key for a patient; selecting a first data set and a second data set from patient-specific medical data; tokenizing a first dataset of patient specific medical data into one or more first non-fungible tokens; tokenizing a second dataset of patient-specific medical data into one or more second non-fungible tokens; receiving at least one digital key; and in response to receiving the at least one digital key, unlocking one or more first non-fungible tokens and one or more second non-fungible tokens linked to the at least one digital key. 24. Identifying a user who transmitted at least one received digital key; bundling the one or more first non-fungible tokens and the one or more second non-fungible tokens into a bundling NFT; 24. The computer-implemented method of example 23, wherein at least one digital key unlocks the bundling NFT for the user. 25. Bundling at least one of the one or more first non-fungible tokens and the one or more second non-fungible tokens into a bundling NFT; Bundling NFTs, Generate a surgical plan based on the data contained in the bundling NFT, transmitting to a surgical plan generation system configured to generate a surgical plan NFT including the surgical plan; The computer-implemented method of Examples 23-24, further comprising receiving a surgical plan NFT for review of the surgical plan. 26. The computer-implemented method of Examples 23-25, further comprising tokenizing the patient's implant design into an implant NFT. 27. The computer-implemented method of Examples 23-26, further comprising selecting the first dataset and the second dataset using a trained machine learning model, wherein the trained machine learning model is trained using one or more imaging examination datasets, patient information datasets, EMR datasets, medical-specific training sets, and / or surgical datasets. 28. Using a trained machine learning model trained using a surgical procedure dataset to identify available patient data associated with a surgical procedure; 28. The computer-implemented method of Examples 23-27, further comprising converting the available patient data into one or more of the first data set and the second data set. 29. Creating a digital wallet for patients; storing a private key in a digital wallet of the patient for granting access to at least a portion of the patient-specific medical data; Creating a digital wallet for healthcare providers; The computer-implemented method of any one of Examples 23-28, further comprising storing a public key in the healthcare provider's digital wallet to allow access to the portion of the patient-specific medical data. 30. The computer-implemented method of examples 23-29, further comprising unlocking or locking at least a portion of the one or more first non-fungible tokens or the one or more second non-fungible tokens using the private key and the public key. 31. Receiving cryptocurrency payments; The computer-implemented method of Examples 23-30, further comprising generating one or more transaction NFTs configured to at least one of: authenticate the payment, contain payment information, or track one or more medical devices associated with the payment. 32. One or more processors; and one or more memories storing instructions which, when executed by one or more processors, cause the computing system to perform the process of any one of the methods of claims 23 to 31. 33. A non-transitory computer readable medium storing instructions which, when executed by a computing system, cause the computing system to perform the operations of any one of the methods of claims 23-31. 34. A computer-implemented method for providing a patient-specific medical device, the method comprising: Transforming patient data of the patient into at least one patient NFT; transmitting at least one patient NFT to a medical device designer over a network; receiving a medical device design from a medical device designer via the designer NFT, the medical device design being based on patient data; and causing a patient-specific medical device to be manufactured for the patient according to the medical device design. 35. The computer-implemented method of Example 34, further comprising establishing NFT communication between a healthcare provider who implants the patient-specific medical device, a medical device designer, and a manufacturer who manufactures the patient-specific medical device. 36. The computer-implemented method of any of Examples 34-35, wherein at least one patient NFT includes at least one imaging study NFT, EMR NFT, or medical procedure NFT. 37. Receiving an NFT transmission request from a requester; In response to the NFT transmission request, creating an NFT associated with the requested source data from the requester; 37. The computer-implemented method of any one of Examples 34-36, further comprising sending an NFT from the requester to the recipient to enable the recipient to access the requester data. 38. One or more processors; and one or more memories storing instructions that, when executed by one or more processors, cause the computing system to perform the process of any one of the methods of claims 34 to 37. 39. A non-transitory computer readable medium having instructions stored thereon that, when executed by a computing system, cause the computing system to perform the operations of any one of the methods of claims 34-37. 40. A computer-implemented method for providing patient-specific medical data associated with a blockchain-enabled medical implant implanted within a patient, the method comprising: Transforming patient-specific medical data into at least one non-fungible token; storing at least one non-fungible token; Establishing communication contact with a blockchain-enabled medical implant implanted in the patient's body by a user device using a proximity communication mode; receiving a user request to access patient-specific medical data in at least one non-fungible token; determining an amount of patient-specific medical data in the at least one non-fungible token to provide to the user based on an authentication level of the user associated with the user request; accessing a private key stored in the blockchain-enabled medical implant based on the authentication level to access the patient-specific medical data in the at least one non-fungible token; and transmitting the determined amount of the patient-specific medical data to a user interface of the user. 41. Access to private keys is receiving encoded data from the blockchain enabled medical implant according to a proximity communication mode; and deriving a private key based on decrypting the encoded data using the user's authorization credentials. 42. The computer-implemented method of any of Examples 40-41, wherein the user request includes providing authorization authentication information using a verification mechanism configured for at least one of voice verification, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, providing biometric information, providing geographic location information, or providing an electronic signature to the physician. 43. One or more processors; and one or more memories storing instructions which, when executed by one or more processors, cause the computing system to perform the process of any one of the methods of claims 40 to 42. 44. A non-transitory computer readable medium storing instructions which, when executed by a computing system, cause the computing system to perform the operations of any one of the methods of claims 40-42. 45. A computer-implemented method for providing patient-specific medical data using a non-fungible token platform, the method comprising: receiving patient-specific medical data for a patient from at least one input data source, the patient-specific medical data being associated with a blockchain enabled medical implant implanted within the patient; converting patient-specific medical data into at least one non-fungible token using a non-fungible token platform; storing at least one non-fungible token in a medical digital filing cabinet; Establishing communication contact with the blockchain-enabled medical implant using a proximity mode of communication by a device associated with the user. receiving a request from a user to access patient-specific medical data in at least one non-fungible token; determining an amount of patient-specific medical data in the at least one non-fungible token to provide to the user based on an authentication level of the user; accessing a private key stored in the blockchain-enabled medical implant based on the authentication level to access the patient-specific medical data in the at least one non-fungible token; and transmitting the determined amount of the patient-specific medical data to a user interface of the user. 46. ​​One or more processors; and one or more memories storing instructions that, when executed by one or more processors, cause the computing system to perform the process of the method of claim 45. 47. A non-transitory computer readable medium storing instructions that, when executed by a computing system, cause the computing system to perform the operations of the method of claim 45.

[0123] Those skilled in the art will recognize that it is common within the art to describe devices and / or processes in the manner set forth herein and then use technical techniques to integrate such described devices and / or processes into a data processing system. That is, at least some of the devices and / or processes described herein can be integrated into a data processing system with a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system typically includes one or more of a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application program, one or more interaction devices such as a touchpad or touch screen, and / or a control system including feedback loops and control motors (e.g., feedback for detecting position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication systems and / or network computing / communication systems.

[0124] The subject matter described herein sometimes shows various components contained within or connected with different other components. It should be understood that such shown architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that a desired functionality is achieved. Thus, any two components herein that are combined to achieve a particular functionality may be considered to be "associated" with each other such that a desired functionality is achieved without regard to architecture or intermediate components. Similarly, any two components so associated may also be considered to be "operably connected" or "operably coupled" with each other to achieve a desired functionality, and any two components that may be so associated may also be considered to be "operably coupled" with each other to achieve a desired functionality. Specific examples of operably coupled components include, but are not limited to, components that can be physically connected and / or physically interacting, and / or components that can wirelessly interact and / or wirelessly interacting, and / or components that can logically interact and / or logically interacting.

[0125] The embodiments, features, systems, devices, materials, methods, and techniques described herein may, in some embodiments, be similar to any one or more of the embodiments, features, systems, devices, materials, methods, and techniques described below. U.S. Patent Application No. 16 / 048,167, filed July 27, 2017, entitled "SYSTEMS AND METHODS FOR ASSISTING AND AUGMENTING SURGICAL PROCEDURES"; U.S. Patent Application No. 16 / 242,877, filed January 8, 2019, entitled "SYSTEMS AND METHODS OF ASSISTING A SURGEON WITH SCREW PLACEMENT DURING SPINAL SURGERY"; U.S. Patent Application No. 16 / 207,116, filed December 1, 2018, entitled "SYSTEMS AND METHODS FOR MULTI-PLANAR ORTHOPEDIC ALIGNMENT"; U.S. Patent Application No. 16 / 352,699, filed March 13, 2019, entitled "SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANT FIXATION"; U.S. Patent Application No. 16 / 383,215, "SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANT FIXATION," filed April 12, 2019; U.S. Patent Application No. 16 / 569,494, "SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANTS," filed on September 12, 2019; U.S. Patent Application No. 62 / 773,127, filed November 29, 2018, entitled "SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANTS"; U.S. Patent Application No. 62 / 928,909, filed October 31, 2019, entitled "SYSTEMS AND METHODS FOR DESIGNING ORTHOPEDIC IMPLANTS BASED ON TISSUE CHARACTERISTICS"; U.S. Patent Application No. 16 / 735,222, filed January 6, 2020, entitled "PATIENT-SPECIFIC MEDICAL PROCEDURES AND DEVICES, AND ASSOCIATED SYSTEMS AND METHODS"; U.S. Patent Application No. 16 / 987,113, filed on August 6, 2020, entitled "PATIENT-SPECIFIC ARTIFICIAL DISCS, IMPLANTS AND ASSOCIATED SYSTEMS AND METHODS"; U.S. Patent Application No. 16 / 990,810, filed on August 11, 2020, entitled "LINKING PATIENT-SPECIFIC MEDICAL DEVICES WITH PATIENT-SPECIFIC DATA, AND ASSOCIATED SYSTEMS, DEVICES, AND METHODS"; U.S. Patent Application No. 17 / 463,054, "BLOCKCHAIN ​​MANAGED MEDICAL IMPLANTS," filed on August 31, 2021; International Patent Application No. PCT / US22 / 42188, "BLOCKCHAIN ​​MANAGED MEDICAL IMPLANTS," filed on August 31, 2022; U.S. Patent Application No. 17 / 085,564, filed on October 30, 2020, entitled "SYSTEMS AND METHODS FOR DESIGNING ORTHOPEDIC IMPLANTS BASED ON TISSUE CHARACTERISTICS," and U.S. Patent Application No. 17 / 100,396, "PATIENT-SPECIFIC VERTEBRAL IMPLANTS WITH POSITIONING FEATURES," filed November 20, 2020.

[0126] All of the above identified patents and applications are incorporated by reference in their entirety. In addition, the embodiments, features, systems, devices, materials, methods, and techniques described herein may, in an embodiment, be applied to or used in connection with any one or more of the embodiments, features, systems, devices, or other methods.

[0127] The ranges disclosed herein also encompass any and all overlaps, subranges, and combinations thereof. Language such as "up to," "at least," "greater than," "less than," "between" includes the recited number. Numbers preceded by terms such as "approximately," "about," and "substantially" as used herein include the recited number (e.g., about 10%=10%) and also represent an amount close to the recited amount that still performs the desired function or achieves the desired result. For example, the terms "approximately," "about," and "substantially" may refer to an amount within less than 10%, within less than 5%, within less than 1%, within less than 0.1%, and within less than 0.01% of the recited amount.

[0128] From the foregoing, it will be understood that various embodiments of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various embodiments disclosed herein are not intended to be limiting.

Claims

1. 1. A computer-implemented method for providing patient-specific medical data using a non-fungible token platform, the method comprising: receiving patient-specific medical data for a patient from at least one input data source; converting the patient-specific medical data into at least one non-fungible token using the non-fungible token platform; storing the at least one non-fungible token in a medical digital filing cabinet; managing access to the at least one non-fungible token based on at least one access parameter; receiving a request by a user to access medical data specific to the patient in the at least one non-fungible token; determining an amount of the patient-specific medical data in the at least one non-fungible token to provide to the user based on an authentication level of the user and the at least one access parameter; and transmitting the determined amount of the patient-specific medical data to a user interface of the user.

2. The patient-specific medical data is associated with a blockchain-enabled medical implant implanted within the patient, and the method comprises: establishing communication contact with said blockchain enabled medical implant using a proximity communication mode; 2. The computer-implemented method of claim 1, further comprising: accessing a private key stored in the blockchain enabled medical implant based on the authentication level to access medical data specific to the patient in the at least one non-fungible token.

3. Accessing the private key receiving encoded data from the blockchain enabled medical implant in the patient according to the proximity communication mode; 3. The computer-implemented method of claim 2, further comprising: deriving the private key based on decrypting the encoded data using authorization credentials of the user.

4. 10. The computer-implemented method of claim 1, wherein the request includes providing the user's authorization authentication information using a verification mechanism, the verification mechanism being voice verification, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, providing biometric information, providing geographic location information, or providing an electronic signature to a physician.

5. determining a type of medical data specific to the patient stored in the at least one non-fungible token; and generating the at least one access parameter based on the type of medical data specific to the patient.

6. creating a digital wallet for the patient; 2. The computer-implemented method of claim 1, further comprising: storing a private key and a public key of the at least one non-fungible token in the digital wallet.

7. 10. The computer-implemented method of claim 1, wherein each transaction of the at least one non-fungible token is associated with an amount of cryptocurrency.

8. 2. The computer-implemented method of claim 1, wherein the medical digital filing cabinet is part of a distributed ledger of the non-fungible token platform, the distributed ledger storing the at least one non-fungible token containing medical data specific to the patient.

9. 10. The computer-implemented method of claim 1, wherein the medical digital filing cabinet includes a digital patient NFT wallet owned by the patient.

10. 10. A non-transitory computer-readable medium storing instructions that, when executed by a computing system, cause the computing system to perform the computer-implemented method of any one of claims 1 to 9.

11. one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the system to perform the computer-implemented method of any one of claims 1 to 9.

12. 1. A computer-implemented method for providing patient-specific medical data of a patient using a non-fungible token platform, the method comprising: generating at least one digital key for said patient; selecting a first data set and a second data set from the patient-specific medical data; tokenizing the first dataset of patient-specific medical data into one or more first non-fungible tokens; tokenizing a second dataset of the patient-specific medical data into one or more second non-fungible tokens; receiving the at least one digital key; and in response to receiving the at least one digital key, unlocking the one or more first non-fungible tokens and the one or more second non-fungible tokens linked to the at least one digital key.

13. identifying a user who transmitted the received at least one digital key; bundling the one or more first non-fungible tokens and the one or more second non-fungible tokens into a bundling NFT; The computer-implemented method of claim 12 , wherein the at least one digital key unlocks the bundling NFT for the user.

14. bundling at least one of the one or more first non-fungible tokens and the one or more second non-fungible tokens into a bundling NFT; The bundling NFT, generating a surgical plan based on the data contained in the bundling NFT; transmitting to a surgical plan generation system configured to generate a surgical plan NFT containing the surgical plan; 13. The computer-implemented method of claim 12, further comprising receiving the surgical plan NFT for review of the surgical plan.

15. 13. The computer-implemented method of claim 12, further comprising tokenizing the patient implant design into an implant NFT.

16. 13. The computer-implemented method of claim 12, further comprising selecting the first data set and the second data set using a trained machine learning model, wherein the trained machine learning model is trained using one or more of an imaging exam data set, a patient information data set, an EMR data set, a medical practice-specific training set, and / or a surgical data set.

17. using a trained machine learning model trained using the surgical procedure dataset to identify available patient data associated with the surgical procedure; 13. The computer-implemented method of claim 12, further comprising: converting the available patient data into one or more of the first data set and the second data set.

18. Creating a patient digital wallet; storing a private key in the patient's digital wallet to allow access to at least a portion of the patient's unique medical data; Creating a digital wallet for healthcare providers; 13. The computer-implemented method of claim 12, further comprising storing a public key in the healthcare provider's digital wallet to grant access to the portion of the patient-specific medical data.

19. 20. The computer-implemented method of claim 18, further comprising using the private key and the public key to unlock or lock at least a portion of the one or more first non-fungible tokens or the one or more second non-fungible tokens.

20. receiving cryptocurrency payments; 20. The computer-implemented method of claim 18, further comprising generating one or more transaction NFTs configured to at least one of authenticate the payment, contain payment information, or track one or more medical devices associated with the payment.

21. 1. A computer-implemented method for providing a patient-specific medical device, the method comprising: Transforming patient data for a patient into at least one patient NFT; transmitting the at least one patient NFT to a medical device designer over a network; receiving a medical device design from the medical device designer via a designer NFT, the medical device design being based on the patient data; causing a patient-specific medical device to be manufactured for the patient in accordance with the medical device design.

22. 22. The computer-implemented method of claim 21, further comprising establishing NFT communication between a healthcare provider who implants the patient-specific medical device, the medical device designer, and a manufacturer who produces the patient-specific medical device.

23. 22. The computer-implemented method of claim 21, wherein the at least one patient NFT comprises at least one imaging study NFT, EMR NFT, or medical procedure NFT.

24. receiving an NFT transmission request from a requestor; Responsive to the NFT transmission request, creating an NFT associated with requested source data from the requestor; 22. The computer-implemented method of claim 21, further comprising transmitting the NFT from the requestor to a recipient, allowing the recipient to access the requestor data.

25. 1. A computer-implemented method for providing patient-specific medical data associated with a blockchain-enabled medical implant implanted within a patient, the method comprising: converting the patient-specific medical data into at least one non-fungible token; storing said at least one non-fungible token; establishing communication contact with the blockchain enabled medical implant implanted within the body of the patient by a user device using a proximity communication mode; receiving a user request to access medical data specific to the patient in the at least one non-fungible token; determining an amount of the patient-specific medical data in the at least one non-fungible token to provide to the user based on an authentication level of the user associated with the user request; accessing a private key stored in the blockchain enabled medical implant based on the authentication level to access medical data specific to the patient in the at least one non-fungible token; and transmitting the determined amount of the patient-specific medical data to a user interface of the user.

26. Accessing the private key receiving encoded data from the blockchain enabled medical implant according to the proximity communication mode; 26. The computer-implemented method of claim 25, further comprising deriving the private key based on decrypting the encoded data using authorization credentials of the user.

27. 26. The computer-implemented method of claim 25, wherein the user request includes providing authorization authentication information using a verification mechanism configured for at least one of voice verification, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, providing biometric information, providing geographic location information, or providing an electronic signature to a physician.

Images