BLOCKCHAIN MANAGED MEDICAL IMPLANTS

Abstract

Systems and methods for tracking patient medical records using a medical implant are described herein. The medical implant can comprise a physical structure configured to secure the medical implant within a body of a patient, a proximity communication component physically coupled to the physical structure, and a memory operatively coupled to the proximity communication component. The memory can store a private key, wherein the memory is configured to provide the private key through the proximity communication component to an external device for enabling the external device to access one or more electronic medical records associated with a patient that is implanted with the implant from a distributed blockchain ledger of electronic medical records.

Description

BACKGROUND

Blockchain technology is used to transfer assets using tokens generated as part of a blockchain encryption process. An asset (e.g., an electronic coin, a blockchain-based good, a personal identifier, and so on) is represented by a chain of transactions that transfers ownership from one party to another party. To transfer ownership of an asset on a blockchain, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key. Once the block is full, the block is “capped” with a block header that is a hash digest of all the transaction identifiers within the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a “blockchain.” To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction. The new owner need only have the private key that matches the public key of the transaction that transferred the asset. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which can be pseudo-anonymous.

The blockchain technology can maintain a distributed ledger of transactions. With a distributed ledger, a ledger of all the transactions for an asset is stored redundantly at multiple nodes (i.e., computers) of a blockchain network. The ledger at each node is stored as a blockchain. In a blockchain, the transactions are stored in the order that the transactions are received by the nodes. Each node in the blockchain network has a complete replica of the entire blockchain. The blockchain system also implements techniques to ensure that each node will store the identical blockchain, even though nodes can receive transactions in different orderings. To verify that the transactions in a ledger stored at a node are correct, the blocks in the blockchain can be accessed from oldest to newest, generating a new hash of the block and comparing the new hash to the hash generated when the block was created. If the hashes are the same, then the transactions in the block are verified. The blockchain system also implements techniques to ensure that it would be infeasible to change a transaction and regenerate the blockchain by employing a computationally expensive technique to generate a nonce that is added to the block when it is created. A blockchain ledger is sometimes referred to as an Unspent Transaction Output (“UXTO”) set because it tracks the output of all transactions that have not yet been spent.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram showing some of the components typically incorporated in at least some of the computer systems and other devices on which the disclosed system operates.

FIG. 1B is a diagram illustrating an example medical implant in accordance with embodiments of the technology.

FIG. 2 is a system diagram illustrating an example of a computing environment in which the disclosed system operates in some embodiments.

FIG. 3 is a block diagram illustrating components which, in some implementations, can be used in a system employing the disclosed technology.

FIG. 4 is a flow chart illustrating an example process for creating patient data in a ledger stored on a medical implant.

FIG. 5 is a flow chart illustrating an example process for accessing a patient's medical records.

DETAILED DESCRIPTION

Blockchain technology can be used to generate an identity token for a physical or digital asset using a cryptographic one-way hash of information that uniquely identifies the asset. Tokens also have an owner that uses an additional public/private key pair. The owner public key is set as the token owner identity and when performing actions against tokens, ownership proof is established by providing a signature generated by the owner private key and validated against the public key listed as the owner of the token. This allows transactions of digital assets, such as records associated with owners of unique tokens, to be accurately tracked using blockchain transactions.

The blockchain technology can maintain a distributed ledger of transactions and generate an identity token for a physical or digital asset using a cryptographic one-way hash of information that uniquely identifies the asset. Tokens also have an owner that uses an additional public/private key pair. The owner public key is set as the token owner identity and when performing actions against tokens, ownership proof is established by providing a signature generated by the owner private key and validated against the public key listed as the owner of the token. A person can be uniquely identified, for example, using a combination of a user name, social security number, and biometric information (e.g., fingerprint). A product (e.g., refrigerator) can be uniquely identified, for example, using the name of its manufacturer and its seral number. The identity tokens for each would be a cryptographic one-way hash of such combinations. The identity token for an entity (e.g., person or company) can be the public key of a public/private key pair, where the private key is held by the entity. Identity tokens can be used to identify people, institutions, commodities, contracts, computer code, equities, derivatives, bonds, insurance, loans, documents, and so on. Identity tokens can also be used to identify collections of assets. An identity token for a collection can be a cryptographic one-way hash of the digital tokens of the assets in the collection. The creation of an identity token for an asset in a blockchain establishes provenance of the asset, and the identity token can be used in transactions (e.g., buying, selling, insuring) of the asset stored in a blockchain, creating a full audit trail of the transactions.

To record a simple transaction in a blockchain, each party and asset involved with the transaction needs an account that is identified by a digital token. For example, when one person wants to transfer a car to another person, the current owner and next owner create accounts, and the current owner also creates an account that is uniquely identified by its vehicle identification number. The account for the car identifies the current owner. The current owner creates a transaction against the account for the car that indicates that the transaction is a transfer of ownership, indicates the public keys (i.e., identity tokens) of the current owner and the next owner, and indicates the identity token of the car. The transaction is signed by the private key of the current owner and the transaction is evidence that the next owner is now the current owner.

In order to limit the visibility of the data on a blockchain, a private blockchain can be employed. A private blockchain acts as a state channel where several parties can share contract states without writing to the main network blockchain. A governance contract is deployed to the private chain for one or more users with governing roles to manage membership and permissions to update state on the private chain. The private blockchain can manage electronic medical records with manage permissions.

For example, electronic medical records (“EMR” or “EMRs”) can be tracked for patients using blockchain transactions. As patients undergo medical procedures, each medical procedure can be recorded as a “transaction” for a blockchain associated with the patient's EMR. Each procedure can include information about the procedure, such as procedure type, date of procedure, outcome of procedure, follow-up actions for the procedure, data associated with the procedure, and/or other information associated with the procedure. New patient data can also be recorded as a transaction.

In order to comply with the Health Insurance Portability and Accountability Act (“HIPAA”), medical records for patients must be kept confidential unless the patient consents to sharing the medical records. While blockchains can be kept private, most blockchains are in the public space so that transactions in the ledger associated with the blockchain can be verified. In order to keep medical records confidential for patients but maintain a ledger of medical procedures as transactions for the patients, a medical implant with computing components, such as persistent memory, can be used to store medical records associated with treatment of the patient, ledger information, and/or a private key for accessing private medical records stored in a blockchain ledger. When the patient wishes to share EMRs with treatment providers, the patient can provide a key unique to the patient's implant chip to the treatment provider, which allows the treatment provider to access the ledger of medical procedures, patient data (e.g., medical history, physician notes, medical images, and scans), surgical plans, healthcare provider information, implant data, and other relevant medical data from the implant itself or from the private ledger that requires the key to access. In some embodiments, the patient can set permissions for access to, for example, selected portion(s) of EMRs.

FIG. 1A is a block diagram showing some of the components typically incorporated in at least some of the computer systems and other devices on which the disclosed system operates. In various embodiments, these computer systems and other devices 100 can include server computer systems, desktop computer systems, laptop computer systems, netbooks, mobile phones, personal digital assistants, televisions, cameras, automobile computers, electronic media players, web services, mobile devices, watches, wearables, glasses, smartphones, tablets, smart displays, virtual reality devices, augmented reality devices, etc. In various embodiments, the computer systems and devices include zero or more of each of the following: a central processing unit (CPU) 101 for executing computer programs; a computer memory 102 for storing programs and data while they are being used, including the facility and associated data, an operating system including a kernel, and device drivers; a persistent storage device 103, such as a hard drive or flash drive for persistently storing programs and data; computer-readable media drives 104 that are tangible storage means that do not include a transitory, propagating signal, such as a floppy, CD-ROM, or DVD drive, for reading programs and data stored on a computer-readable medium; and a network connection 105 for connecting the computer system to other computer systems to send and/or receive data, such as via the Internet or another network and its networking hardware, such as switches, routers, repeaters, electrical cables and optical fibers, light emitters and receivers, radio transmitters and receivers, and the like. While computer systems configured as described above are typically used to support the operation of the facility, those skilled in the art will appreciate that the facility may be implemented using devices of various types and configurations, and having various components.

FIG. 1B illustrates an example medical implant 150 according to some embodiments of the invention. The medical implant 150 can be an intervertebral device that includes a body 152 configured to interface with one or more identified anatomical structures (e.g., one or more vertebral bodies or endplates) at and/or proximate the target implantation site (e.g., between one or more vertebral bodies or endplates). The implant body 152 can include one or more structural features designed to engage one or more identified anatomical structures. For example, in the illustrated embodiment, the implant 150 can include an upper surface 165 and a lower surface (not shown) configured to seat against vertebral bodies of spine. In some embodiments, the upper surface 165 and the lower surface can have contours that match contours of the vertebral endplates, such that the upper surface 165 and lower surface “mate” with the corresponding vertebral endplates they engage with. 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., via roughenings, knurlings, ridges, and the like). Texturing data can be part of manufacturing data stored in the EMRs. For lordotic correction, the upper surface 165 and the lower surface may be angled with respect to one another, and the EMR can include the angle and sizes of these surfaces.

In some embodiments, the implant 150 can be an interspinous spacer with structural features in the form of U-shaped portions designed to receive respective spinous processes. The dimensions of the U-shaped portions can match the dimensions of the spinous processes. In other embodiments, the structural features can include recesses, arms, or other contact features designed to engage (e.g., contact, receive, etc.) one or more anatomical features (e.g., tissue, bony structures, etc.). The EMR can include the implant configuration, features, implantation procedure/plan, and/or intended use.

A user (e.g., a physician, health care provider, etc.) can access EMRs using a retrieval feature 160. For example, in embodiments in which a retrieval feature 160 is a bar code corresponding to the unique identifier, the user can scan the retrieval feature 160 using, for example, one or more cameras on the computing device and/or otherwise input the unique identifier into the computing device. Once the unique identifier is inputted into the computing system, the computing system can send the unique identifier to a remote server (e.g., via a communication network) with a request to provide the corresponding patient-specific surgical data set. In response to the request, and as described above, the server can locate the specific 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 features assisting with accessing the ledger and viewing the EMRs.

Additional implant types, configurations, and structural features suitable for engaging identified anatomical features are described, for example, in U.S. application Ser. No. 16/207,116, filed Dec. 1, 2018, and U.S. application Ser. No. 16/987,113, filed Aug. 6, 2020, the disclosures of which are incorporated by reference herein in their entireties. For example, the medical implants can be pedicle screws, patient-specific implants, interbody implant systems, artificial discs, expandable intervertebral implants, sacroiliac implants, plates, arthroplasty devices for orthopedic joints, non-structural implants, or other devices disclosed in the patents and applications incorporated herein by reference.

The medical implant 150 is used to track and monitor medical data associated with the patient. U.S. Application No. 63/218,190 discloses implants capable of collecting data, assigning weighting/values, and communicating with other devices. The monitoring can be used with prescriptive systems, such as the systems disclosed in U.S. Pat. No. 10,902,944 and U.S. application Ser. No. 17/342,439, which are incorporated by reference in their entireties. For example, the patient's data can be incorporated into one or more training sets for a machine learning system or other systems disclosed in the incorporated by reference patents and applications.

The medical implant 150 can also be a multipurpose implant, providing both structure to address a medical issue in the body of the patient while also carrying information regarding the patient. For example, the medical implant 150 can be a pacemaker, a plate or pin to correctly position a previously broken bone or set of bones, and the like.

The retrieval feature 160 can be used to carry patient data, such as a private key for unlocking patient medical records stored on a blockchain ledger. In some implementations, the medical implant 150 also contains a private blockchain ledger for tracking EMRs associated with the patient. As the patient undergoes various treatments, new EMRs and updates to existing EMRs for the patient are generated and stored as “transactions” in a blockchain ledger. To access the EMRs associated with the patient, the private key from the medical implant 150 must be used to “unlock” the EMRs stored in the blockchain ledger. The patient can provide this private key to health care providers and other interested parties by a secure platform, mobile application, digital key, or the like. In some embodiments, the EMRs are encrypted using an encryption key that the health care provider decrypts. Additionally or alternatively, re-keying protocols, certification management protocols (e.g., enrollment certification protocol, transaction certification protocol, etc.), and other protocols and can be utilized for variable access and permissions. The patient can manage the data of the EMR to share selected data only. For example, the patient can a keep section of the EMR private while sharing another section of the EMR. The system also allows for user-controlled settings, such as settings for minors, family members, relatives, and/or other user-controlled settings.

An EMR can include patient data associated with the implant design and design process. If the implant is an artificial disc, for example, the stored data can include kinematic data (e.g., pre-operative patient data, target kinematic data, etc.), manufacturing data, design parameters, target service life data, physician recommendations/notes, etc. The disc can include an articulating implant body with plates contoured to match vertebral endplates, custom articulating members between the plates for providing patient-specific motion, etc. If the implant is an intervertebral cage, the stored data can include materials specifications of the implant body, dimensions of the implant body, manufacturing data, design parameters, target service life data, physician recommendations/notes, etc. The applications and patents incorporated by reference disclose data (e.g., surgical plans, implant specifications, data sets, etc.) that can be associated with the retrieval feature 160.

In some implementations, the patient can set variable permissions for access to transactions and details stored in the blockchain ledger. For example, particular medical providers may only be given access to certain transactions related to particular kinds of medical procedures. In other implementations, permissions can be set based on the patient, such as having child settings for children with an implant.

The medical implant 150 can also track and monitor various health related data for the patient. For example, the medical implant 150 can include one or more sensors configured to measure pressures, loads, or forces applied by anatomical elements to monitor, for example, activity, loading, etc. The medical implant 150 can continuously or periodically collect data indicating activity level, activities performed, disease progression, or the like. For example, loading across the implant 150 can be tracked over period of time. The applications and patents incorporated by reference disclose techniques for monitoring, collecting data, and transmitting data. In some embodiments, the medical implant 150 can identify events, such as excess loading, imbalance of the spine, or the like. In some embodiments, the patient is monitored with automatic blockchain updating based on activity (e.g., surgical procedure, change in status, etc.), disability (e.g., new disability, progression of disability, etc.), and/or healthcare events. The health care events can include imaging, diagnosis, treatment, and/or outcomes and event data that can be encoded in the blockchain. Collected data can be used as historical patient data used to treat another patient. The applications and patents incorporated by reference also disclose usage of historical data, imaging data, surgical plans, simulations, modeled outcomes, treatment protocols, and outcome values that can be encoded in the blockchain.

In some implementations, two or more implants can be used. For example, a patient can have both a spinal implant with an encoded chip containing the private key and/or the private blockchain ledger containing the EMRs of the patient and a subcutaneous digital implant. The subcutaneous digital implant acts as an intermediary device, communicating with both the spinal implant containing the private key and/or the private blockchain ledger and an external computing device, such as a patient treatment computing system. The subcutaneous digital implant may also include data of its own, such as patient identifying information, biometric data, and the like. In some embodiments, the subcutaneous digital implant may include the private key and/or the private blockchain ledger containing the EMRs of the patient.

FIG. 2 is a system diagram illustrating an example of a computing environment in which the disclosed system operates in some embodiments. In some embodiments, environment 200 includes one or more client computing devices 205A-D, examples of which can host the system 100. Client computing devices 205 operate in a networked environment using logical connections through network 230 to one or more remote computers, such as a server computing device. In some implementations, the client computing devices 205 can also include a medical implant, such as the medical implant 150 described above in relation to FIG. 1B.

In some embodiments, server 210 is an edge server which receives client requests and coordinates fulfillment of those requests through other servers, such as servers 220A-C. In some embodiments, server computing devices 210 and 220 comprise computing systems, such as the system 100. Though each server computing device 210 and 220 is displayed logically as a single server, server computing devices can each be a distributed computing environment encompassing multiple computing devices located at the same or at geographically disparate physical locations. In some embodiments, each server 220 corresponds to a group of servers.

Client computing devices 205 and server computing devices 210 and 220 can each act as a server or client to other server or client devices. In some embodiments, servers (210, 220A-C) connect to a corresponding database (215, 225A-C). As discussed above, each server 220 can correspond to a group of servers, and each of these servers can share a database or can have its own database. Databases 215 and 225 warehouse (e.g., store) information such as biometric information of users, blockchain transactions involving user medical records, and other data. Though databases 215 and 225 are displayed logically as single units, databases 215 and 225 can each be a distributed computing environment encompassing multiple computing devices, can be located within their corresponding server, or can be located at the same or at geographically disparate physical locations.

Network 230 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, network 230 is the Internet or some other public or private network. Client computing devices 205 are connected to network 230 through a network interface, such as by wired or wireless communication. While the connections between server 210 and servers 220 are shown as separate connections, these connections can be any kind of local, wide area, wired, or wireless network, including network 230 or a separate public or private network.

FIG. 3 is a block diagram illustrating components 300 which, in some implementations, can be used in a system employing the disclosed technology. The components 300 include hardware 302, general software 320, and specialized components 340. As discussed above, a system implementing the disclosed technology can use various hardware including processing units 304 (e.g. CPUs, GPUs, APUs, etc.), working memory 306, storage memory 308 (local storage or as an interface to remote storage, such as storage 215 or 225), and input and output devices 310. In various implementations, storage memory 308 can be one or more of: local devices, interfaces to remote storage devices, or combinations thereof. For example, storage memory 308 can be a set of one or more hard drives (e.g. a redundant array of independent disks (RAID)) accessible through a system bus or can be a cloud storage provider or other network storage accessible via one or more communications networks (e.g. a network accessible storage (NAS) device, such as storage 215 or storage provided through another server 220). Components 300 can be implemented in a client computing device such as client computing devices 205 or on a server computing device, such as server computing device 210 or 220.

General software 320 can include various applications including an operating system 322, local programs 324, and a basic input output system (BIOS) 326. Specialized components 340 can be subcomponents of a general software application 320, such as local programs 324. Specialized components 340 can include a blockchain module 344, EMR module 346, patient treatment data module 348, and components which can be used for providing user interfaces, transferring data, and controlling the specialized components, such as interfaces 342. In some implementations, components 300 can be in a computing system that is distributed across multiple computing devices or can be an interface to a server-based application executing one or more of specialized components 340. Although depicted as separate components, specialized components 340 may be logical or other nonphysical differentiations of functions and/or may be submodules or code-blocks of one or more applications.

Blockchain module 344 provides blockchain functionality for the system. The blockchain module 344 allows for the creation of a new block for a new/existing blockchain distributed ledger, hashing of the new block, and addition of the new block to the patient's private blockchain and distributed ledger. The blockchain module 344 can manage a plurality of public blockchains, private blockchains, and/or other distributed ledgers for patients. In some implementations, the privacy of each patient's blockchain(s) can be ensured because each patient maintains an individual blockchain and/or ledger for the patient's medical records and data. In other implementations, transactions include a public key that matches a private key associated with the patient. In these implementations, while the transactions are added to a public ledger, details of the transactions can only be accessed when the private key is used, ensuring patient data privacy.

New blocks for blockchains and/or ledgers are based on received EMRs from the EMR module 346. In some implementations, the created blockchain ledger(s) can be stored in persistent memory of an implant of the patient. In other implementations, the created blockchain ledger(s) can be stored in 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 can be associated with different patients, but cannot be accessed for viewing unless a medical professional possesses a private key associated with the patient identified in a particular block in the ledger. Groups of patients can be subdivided in multiple ways. For example, a group of patients can be defined as all patients at a particular medical facility, all patients under the treatment of a particular medical professional, all patients covered by a particular medical insurance provider, all patients with a similar pathology, treatment, outcome, and the like.

EMR module 346 maintains patient electronic medical records. The EMRs can include patient data (e.g., images, scans, etc.), demographic information about the patient, identifying information of the patient, historical patient treatment data, metrics, plans (e.g., pre-operative plans, corrective plans, surgical plans, post-operative plans, etc.), data providing pathology-related information, provider information (e.g., physician, hospital, surgical team, etc.), patient feedback (e.g., feedback acquired 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 illnesses or medical problems, prescription drug history, and the like. EMR module 346 can also maintain patient treatment records, such as medical procedures undergone, implant information (e.g., patient-specific design, composition, implantation date, manufacture, etc.), drug therapies performed, clinical trials participated in, and other relevant medical actions taken on behalf of the health of the patient. Each medical action can also include various additional data points, such as attending physician, prescribing physician, time and date of action, patient medical reaction medical action taken, and other relevant medical data points. In some implementations, EMRs can also include various relevant images and scans (e.g., CT scans, 3D CT scans, CMCT scans, MRIs, PET scans, etc.), images (e.g., X-ray images, magnetic resonance imaging, ultrasound images, etc.) associated with medical actions, such as medical images, blood test results, and the like. The EMR module 346 can provide EMRs to the blockchain module 344 for generating transactions based on the EMRs.

Patient treatment data module 348 gathers patient data regarding a medical event or medical action (e.g., a hospitalization, a medical procedure, a drug therapy regime, and the like) from various medical systems. In one example, patient treatment data module 348 can receive identifying information identifying a patient, a result from a routine physician visit, and any relevant data associated with the 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 treatment data module 348 can provide this data in an EMR to the EMR module 346 to create new EMRs for patients.

FIG. 4 is a flow chart illustrating an example process 400 for creating patient data in a ledger stored on a medical implant.

At block 402, process 400 receives patient treatment information. Patient information can include patient identification information, a patient diagnosis, data associated with a diagnosis, a patient treatment plan, data associated with a patient treatment plan, medical images associated with the diagnosis or treatment plan, EMRs, and/or other patient information associated with patient diagnosis and treatment. The patient treatment information can be received from a patient diagnosis software system, a patient treatment software system, a patient testing software system, and/or other software systems associated with patient diagnosis and treatment.

At block 404, process 400 generates a new transaction based on the received patient treatment information. The transaction includes details of the received patient treatment information and can also include additional information, such as a unique patient identifier, information associated with the physician delivering the treatment, the facility delivering the treatment, and/or other information associated with the treatment. The transaction also includes a public key that allows those with a matching private key to access details of the transaction. The patient has ownership of the private key and can, in the future, share the private key with health care providers to access previous transactions in the ledger.

At block 406, process 400 adds the generated transaction to the blockchain ledger. In some implementations, the transaction is generated at a patient treatment computing system and then transmitted to a blockchain ledger stored on the medical implant via one or more wireless data communication means. The transaction is added to the ledger stored on the medical implant as the most recent transaction and can include all of the details of the transaction. In other implementations, the generated transaction is added to a private distributed ledger in a medical records software system and can only be accessed using the private key stored on the medical implant of the patient. In this implementation, the private key is implanted within the patient. The implanted private key can be configured to reside on an orthopedic, spine, subcutaneous, or another implant. In further implementations, the generated transaction can be added to a public ledger as a private transaction. To access the private transaction from the public ledger, the private key associated with the patient (e.g., the implanted key) must be used. Any user attempting to access the transaction without the key will not be able to see any details associated with the transaction. In this implementation, various patients can have medical records tracked on a public ledger while maintaining health data privacy for each patient.

FIG. 5 is a flow chart illustrating an example process 500 for accessing a patient's medical records.

At block 502, process 500 receives a private key associated with a patient. In some implementations, the private key is received by establishing wireless communicative contact with an implant in the patient. The implant includes a persistent memory containing the private key, which can only be accessed when wireless communicative contact is established between the implant and a computing system executing process 500, such as a patient treatment software system. The private key is unique to the patient and is the only way to access records associated with the patient. In some implementations, a request for the private key can be generated by the computing system executing process 500. The request can include a request for patient authorization to access the private key.

In some implementations, the patient may be required to agree to share the private key from the implant with process 500. For example, a confirmation mechanism, such as voice confirmation, entering a password into a software application, web application, mobile application, or the like, providing an e-signature to a physician, or another appropriate confirmation mechanism can be used. The private key from the implant can be shared using telecommunication methods such as radio frequency and other modes of proximity telecommunication technology. Until the patient successfully confirms that the private key can be shared, the private key will not be provided to the physician or medical treatment provider.

As an illustrative example, the patient authorization may include a user password, an access code/phrase, or the like that may be used to decrypt the data read from the medical implant. One or more of the components 300 (e.g., the blockchain module 344) can use the user password, etc. to decrypt the data provided by the medical implant using one or more predetermined decryption mechanisms, thereby accessing the private key. Alternatively or additionally, the patient authorization may be specifically tied to one or more user accounts. For example, the patient may provide or preset authorizations, different access levels, and/or access conditions for accounts belonging to one or more specific healthcare provider personnel (e.g., a primary care provider or a designated specialist), a generic category of healthcare providers, a family member, an authorized/selected advocate, or the like. The person/entity attempting to access the private key may be required to use a corresponding account, and the account information may be used to grant access to the private key.

The medical implant and the corresponding system can vary the access levels according to conditions, such as for certain medical emergencies. For example, an emergency care provider or a family member may be granted access to the private key (by, e.g., one or more methods/mechanisms described above) when the patient conditions (e.g., physiological markers and/or conditions reported by patient devices) match one or more predetermined patterns. The patient condition may be determined through the interfacing medical implant, which may be coupled to one or more other devices (e.g., wearable health monitors) or implants associated with the user. The attempt to access the private keys can initiate or power (such as for RFID or NFC communication protocols) the interfacing medical implant and/or other devices to conduct a status check. When the status check matches an emergency condition (e.g., one of predetermined template scenarios and/or thresholds), the interfacing medical implant can provide an indication for the receiving system. Based on the received indication, the system can allow a predetermined set of account holders to access the private key and/or authorized portions of the EMR.

At block 504, process 500 uses the received private key to access a blockchain ledger containing EMRs of the patient. In some implementations, the blockchain ledger is a private blockchain ledger stored in persistent memory on the implant of the patient. In these implementations, process 500 establishes or maintains wireless communicative contact with the implant, uses the private key to “unlock” the blockchain ledger, and then receives the blockchain ledger from the implant for viewing by the physician. In some embodiments, the physician can modify the unlocked blockchain ledger to include additional patient data, such as new scans, diagnosis, test results, or the like. In other implementations, process 500 uses the received private key to “unlock” a private blockchain ledger or access one or more blocks associated with the patient in a public blockchain ledger.

At block 506, process 500 displays the accessed EMRs of the patient to the health care provider in possession of the private key. EMRs can be presented in familiar formats including tables, databases, charts, graphics, or text. The applications and patents incorporated by reference also disclose example EMRs.

CONCLUSION

Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to.” As used herein, the terms “connected,” “coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof. Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word “or,” in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

The above Detailed Description of examples of the technology is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific examples for the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the technology, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or sub-combinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Further, any specific numbers noted herein are only examples: alternative embodiments may employ differing values or ranges.

The teachings of the technology provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various examples described above can be combined to provide further embodiments of the technology. Some alternative embodiments of the technology may include not only additional elements to those embodiments noted above, but also may include fewer elements.

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 in the following:

• • U.S. application Ser. No. 16/048,167, filed on Jul. 27, 2018, titled “SYSTEMS AND METHODS FOR ASSISTING AND AUGMENTING SURGICAL PROCEDURES”;
  • U.S. application Ser. No. 16/242,877, filed on Jan. 8, 2019, titled “SYSTEMS AND METHODS OF ASSISTING A SURGEON WITH SCREW PLACEMENT DURING SPINAL SURGERY”;
  • U.S. application Ser. No. 16/207,116, filed on Dec. 1, 2018, titled “SYSTEMS AND METHODS FOR MULTI-PLANAR ORTHOPEDIC ALIGNMENT”;
  • U.S. application Ser. No. 16/352,699, filed on Mar. 13, 2019, titled “SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANT FIXATION”;
  • U.S. application Ser. No. 16/383,215, filed on Apr. 12, 2019, titled “SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANT FIXATION”;
  • U.S. application Ser. No. 16/569,494, filed on Sep. 12, 2019, titled “SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANTS”;
  • U.S. application Ser. No. 16/699,447, filed on Nov. 29, 2019, titled “SYSTEMS AND METHODS FOR ORTHOPEDIC IMPLANTS”;
  • U.S. application Ser. No. 17/085,564, filed on Oct. 30, 2020, titled “SYSTEMS AND METHODS FOR DESIGNING ORTHOPEDIC IMPLANTS BASED ON TISSUE CHARACTERISTICS”;
  • U.S. application Ser. No. 16/735,222, filed Jan. 6, 2020, titled “PATIENT-SPECIFIC MEDICAL PROCEDURES AND DEVICES, AND ASSOCIATED SYSTEMS AND METHODS”;
  • U.S. application Ser. No. 16/987,113, filed Aug. 6, 2020, titled “PATIENT-SPECIFIC ARTIFICIAL DISCS, IMPLANTS AND ASSOCIATED SYSTEMS AND METHODS”;
  • U.S. application Ser. No. 17/100,396, filed Nov. 20, 2020, titled “PATIENT-SPECIFIC VERTEBRAL IMPLANTS WITH POSITIONING FEATURES”; and
  • U.S. application Ser. No. 17/342,439, filed Jun. 8, 2021, titled “PATIENT-SPECIFIC MEDICAL PROCEDURES AND DEVICES, AND ASSOCIATED SYSTEMS AND METHODS.”

All of the above-identified patents and applications are incorporated by reference in their entireties.

These and other changes can be made to the technology in light of the above Detailed Description. While the above description describes certain examples of the technology, and describes the best mode contemplated, no matter how detailed the above appears in text, the technology can be practiced in many ways. Details of the system may vary considerably in its specific implementation, while still being encompassed by the technology disclosed herein. As noted above, specific terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the technology to the specific examples disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the claims.

To reduce the number of claims, certain aspects of the technology are presented below in certain claim forms, but the applicant contemplates the various aspects of the technology in any number of claim forms. For example, while only one aspect of the technology is recited as a computer-readable medium claim, other aspects may likewise be embodied as a computer-readable medium claim, or in other forms, such as being embodied in a means-plus-function claim. Any claims intended to be treated under 35 U.S.C. § 112(f) will begin with the words “means for,” but use of the term “for” in any other context is not intended to invoke treatment under 35 U.S.C. § 112(f). Accordingly, the applicant reserves the right to pursue additional claims after filing this application to pursue such additional claim forms, in either this application or in a continuing application.

Claims

1. A method for managing patient medical records, the method comprising:

generating a request for a private key associated with a patient, the request including a request for patient authorization to access the private key;

receiving patient authorization to access the private key;

establishing communicative contact with a blockchain-enabled medical implant that is implanted in a body of the patient, the communicative contact being established using a proximity communication mode;

based on the patient authorization, accessing the private key stored on the blockchain-enabled medical implant;

accessing one or more electronic medical records associated with the patient from a distributed ledger of electronic medical records using the received private key, wherein the distributed ledger represents a private blockchain ledger or a public blockchain ledger storing the one or more electronic medical records as private transactions, and each electronic medical record is stored as a hashed transaction in the distributed ledger of electronic medical records, and the private key associated with the patient is used to access details of hashed transactions associated with the patient; and

displaying the one or more electronic medical records associated with the patient.

2. The method of claim 1, wherein the patient provides patient authorization to access the private key using a confirmation mechanism, wherein the confirmation mechanism is a voice confirmation, entering a password into a software application, entering a password into a web application, entering a password into a mobile application, or providing an e-signature to a physician.

3. The method of claim 1, wherein the proximity communication mode is a radio frequency communication mode.

4. The method of claim 3, wherein accessing the private key includes:

receiving encoded data from the blockchain-enabled medical implant according to the radio frequency communication mode; and

deriving the private key based on decrypting the encoded data using the patient authorization or a portion thereof.

5. The method of claim 1, wherein the distributed ledger of electronic medical records is stored in the memory of the blockchain-enabled medical implant.

6. The method of claim 1, wherein

the communicative contact with the blockchain-enabled medical implant is established through an intermediary device that is on or implanted in the body of the patient and communicatively coupled to the blockchain-enabled medical implant; and

the private key is accessed through the intermediary device.

7. The method of claim 1, wherein the one or more accessed electronic medical records corresponds to an access permission setting previously provided by the patient for the access.

8. A method for managing an electronic medical record for a patient, the method comprising:

receiving patient treatment information associated with a patient, the patient treatment information including information associated with patient diagnosis and treatment;

generating an electronic medical record, the electronic medical record including details associated with the received patient treatment information and a unique patient identifier;

generating a blockchain transaction based on the electronic medical record, a public key and a private key, wherein the public key and the private key are a matching pair directly associated with the unique patient identifier, the private key configured for accessing the details of the blockchain transaction, and the private key is stored on a blockchain-enabled medical implant that is implanted in a body of the patient; and

adding the blockchain transaction to a distributed ledger of transactions associated with the patient, wherein the block chain transaction is added to a private ledger or as a private transaction to a public ledger.

9. The method of claim 8, wherein the patient treatment information includes patient data, one or more medical images associated with the patient, one or more scans associated with the patient, demographic information about the patient, identifying information of the patient, historical patient treatment data, metrics, patient treatment plans, data providing pathology-related information of the patient, provider, patient feedback data, vital signs, diagnostic results, patient family history of illnesses or medical problems, and/or prescription drug history of the patient.

10. The method of claim 8, wherein the electronic medical record further includes information associated with the physician delivering treatment to the patient and/or information associated with the facility delivering treatment to the patient.

11. The method of claim 8, wherein the distributed ledger of transactions is the private ledger of transactions associated with the patient, and wherein the private key associated with the patient is required to access the distributed ledger of transactions.

12. The method of claim 11, wherein the distributed ledger of transactions is stored in the memory of the blockchain-enabled medical implant.

13. The method of claim 8, wherein the distributed ledger of transactions is the public ledger of transactions, and wherein the private key associated with the patient is used to access transactions associated with the patient stored on the public ledger of transactions.

14. The method of claim 8, wherein the electronic medical record further includes one or more permissions defining one or more portions of the medical record can be accessed by a particular user.

15-21. (canceled)