[001] This application claims the benefit of U.S. Provisional Patent Application No. 63/312,848 filed on February 23, 2022. This application also claims the benefit of U.S. Provisional Patent Application No. 63/481 ,304 filed on January 24, 2023.

The contents of the above-referenced applications are hereby incorporated by reference.

TECHNICAL FIELD

[002] The present disclosure relates generally to decentralized storage of medical records, and more specifically to processing medical images to be stored and distributed via a decentralized storage platform.

BACKGROUND

[003] In today’s world, personal and medical data have become important appreciating assets. Putting ownership of such data in the hands of the patients whose data is collected would allow consumers to control their own data, and decide how to use and monetize their own data at their discretion.

[004] Some solutions have been proposed to allow patients to store their medical data on a decentralized storage such as via a blockchain. A blockchain is a distributed digital ledger storing transaction data, where the ledger is decentralized insofar as copies of the ledger are stored on multiple computers (nodes) such that each node stores a copy of the blockchain. Because copies of the blockchain are stored across multiple nodes, records cannot be altered on one node in order to falsify the records among the nodes. When new transaction data is to be added to the blockchain, the nodes validate the new transaction data and reach consensus regarding what data should be included in the updated blockchain. When such consensus occurs, transaction data is recorded on the blockchain on each node.

[005] Because blockchain solutions involve storing data across multiple nodes, uploading data to a blockchain can require a significant amount of computing and networking resources. This is compounded for blockchain solutions using proof-of-work algorithms, which are notoriously resource-intensive and energy inefficient.

[006] In the medical data context, a common type of data which is collected for patients includes medical images. Some kinds of medical images are three-dimensional images which contain a significant amount of data. As a particular example, three-dimensional (3D) Cone Beam Computed Tomography (CBCT) images acquired by dentists are often used for planning oral procedures. During a CBCT scan, an imaging machine rotates around a patient’s entire head, capturing hundreds of images from a variety of angles which can be compiled into a single 3D image. In addition to their value as a patient’s dental history, the resulting CBCT images contain features which are indicative of the underlying bone structure which might be utilized to identify indicators of additional nondental medical conditions like osteoporosis, sleep apnea, cysts, sinus infections or inflammations, nasal polyps, carotid artery calcifications (CACs), and jaw-related disorders.

[007] These 3D medical images present a particular challenge to potential blockchain-based medical records, as uploading those 3D images can be extremely costly in terms of the computing resources needed to process the upload, as well as the cost to the consumer in cryptocurrency used to pay for transaction uploading. Even when the 3D images themselves are not stored on a blockchain (e.g., when data including information needed to access the images stored elsewhere), the images may be transmitted over the Internet for recording as transactions or may otherwise be sent for storage in a remote system. As a result, any of these solutions may require a significant amount of computing and networking resources for medical records including 3D images.

[008] Additionally, there is another technical challenge when utilizing 3D images. Specifically, many 3D images contain effectively the same kind of data as 2D images, only several hundred or thousand times more. This large amount of data in 3D images may not fit in a given processor’s memory, thereby making it effectively impossible to process those 3D images using certain processors.

[009] Solutions which facilitate storage of medical data on distributed electronic ledgers such as blockchains would therefore be highly desirable. SUMMARY

[0010] A summary of several example embodiments of the disclosure follows. This summary is provided for the convenience of the reader to provide a basic understanding of such embodiments and does not wholly define the breadth of the disclosure. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments nor to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later. For convenience, the term “some embodiments” or “certain embodiments” may be used herein to refer to a single embodiment or multiple embodiments of the disclosure.

[0011] Certain embodiments disclosed herein include a method for decentralized storage and distribution of reduced data records. The method comprises: reducing at least one image among a set of records data corresponding to a user, wherein reducing the at least one image further comprises identifying at least one region of interest (ROI) in the at least one image and encoding the identified at least one ROI into at least one ROI feature vector; creating a transaction based on the set of records data including the reduced at least one image, wherein the transaction is a collection of data including at least a portion of the set of records data; and uploading the at least one transaction to a decentralized network.

[0012] Certain embodiments disclosed herein also include a non-transitory computer readable medium having stored thereon causing a processing circuitry to execute a process, the process comprising: reducing at least one image among a set of records data corresponding to a user, wherein reducing the at least one image further comprises identifying at least one region of interest (ROI) in the at least one image and encoding the identified at least one ROI into at least one ROI feature vector; creating a transaction based on the set of records data including the reduced at least one image, wherein the transaction is a collection of data including at least a portion of the set of records data; and uploading the at least one transaction to a decentralized network.

[0013] Certain embodiments disclosed herein also include a system for decentralized storage and distribution of reduced data records. The system comprises: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: reduce at least one image among a set of records data corresponding to a user, wherein reducing the at least one image further comprises identifying at least one region of interest (ROI) in the at least one image and encoding the identified at least one ROI into at least one ROI feature vector; create a transaction based on the set of records data including the reduced at least one image, wherein the transaction is a collection of data including at least a portion of the set of records data; and upload the at least one transaction to a decentralized network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will be apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0015] Figure 1 is a network diagram utilized to describe various disclosed embodiments.

[0016] Figure 2 is a flowchart illustrating a method for storing medical records on a decentralized storage platform according to an embodiment.

[0017] Figure 3 is a flowchart illustrating a method for utilizing medical records stored on a decentralized storage platform as identification according to an embodiment.

[0018] Figure 4 is a flowchart illustrating a method for image analysis using reduced images according to an embodiment.

[0019] Figure 5 is a flowchart illustrating a method for performing data reduction on images and analyzing reduced images according to an embodiment.

[0020] Figure 6 is a schematic diagram of a distributed electronic ledger creator according to an embodiment.

[0021] Figure 7 is a diagram illustrating storage of distributed electronic ledgers which may be utilized in accordance with various disclosed embodiments.

[0022] Figure 8 is a data flow diagram illustrating data being provided by a user and prepared for upload to a decentralized storage which may be utilized in accordance with various disclosed embodiments.

[0023] Figure 9 is a smart contract diagram.

[0024] Figure 10 is a diagram illustrating automated processing of user data which may be utilized in accordance with various disclosed embodiments. [0025] Figure 11 is a flow diagram illustrating user control activities with respect to medical data which may be utilized in accordance with various disclosed embodiments.

[0026] Figure 12 is a flow diagram illustrating a process for a data marketplace which may be utilized in accordance with various disclosed embodiments.

[0027] Figure 13 is an example illustration of a patent record system which may be utilized in accordance with various disclosed embodiments.

[0028] Figures 14A-N are various examples of patient data which may be recorded on a decentralized storage in accordance with various disclosed embodiments.

DETAILED DESCRIPTION

[0029] The various disclosed embodiments include techniques for facilitating storage of medical records on decentralized data structures acting as distributed electronic ledgers. More specifically, various disclosed embodiments utilize image reduction techniques that reduce the amount of data to be distributed via such distributed electronic ledgers. Various disclosed embodiments further include techniques that leverage such distributed electronic ledgers for different implementations involving granting users access permissions for medical records stored on the distributed electronic ledger.

[0030] In an embodiment, records to be stored via a decentralized network are obtained. The records may include, but are not limited to, medical images and, in particular, three- dimensional (3D) medical images. The images are reduced and the data including the images may further be optionally enriched, anonymized, or both. Transactions to be uploaded to a distributed electronic ledger are created based on the resulting data. The transactions are uploaded to a decentralized network (e.g., a blockchain network) for validation and storage. Once the transactions have been recorded as distributed electronic ledgers on the decentralized network, user access to the distributed electronic ledgers may be established.

[0031] Records uploaded as transactions to the decentralized network may subsequently be used for purposes such as, but not limited to, identification. To this end, in an embodiment, a user is provided access to a portion of the distributed electronic ledger corresponding to that user’s medical data. More specifically, the user is onboarded via a user device, for example via a website visited via the user device or a computer program installed on the user device. During or after the onboarding, the user may provide user data including medical records to be recorded on a distributed electronic ledger. Such user data is utilized to generate transactions, which are sent for uploading to a decentralized network. Once the transactions are recorded on a distributed electronic ledger via the decentralized network, access to the distributed electronic ledger is obtained so that the user can access at least a portion of the data stored thereon.

[0032] The user data (or portion thereof) uploaded to the decentralized network includes medical records which uniquely identify the user such as, but not limited to, dental images showing the user’s teeth, biopsy images, histological images, combinations thereof, and the like. In other words, such medical records uniquely identify that user such that those medical records only match respective medical records of that user and do not match medical records of other users. Accordingly, user data uploaded to the decentralized network includes enough of that data in order to uniquely identify the user. Thereafter, when the user requests access to their uniquely identifying medical records (e.g., by providing certain user inputs via a computer program installed on a user device of that user), the relevant portion of data may be retrieved from the decentralized network and displayed on the user device, sent to an account associated with the user, or otherwise provided in order to enable the user to show those medical records as identification.

[0033] In addition to the various technical benefits which facilitate uploading of medical records to decentralized storage by reducing the among of computing and networking resources needed to process such uploads, the decentralized storage of such medical records enabled by the disclosed embodiments may be utilized to provide new ways for patients to control their own medical records. This effectively allows for democratizing and/or liberalizing patient data by allowing patients to control access to their medical records. When access is controlled in this manner, patients can access their data as- needed (e.g., in order to readily share them with medical professionals), sell access to their data, or otherwise choose how their data is utilized.

[0034] Additionally, it has been identified that, for some implementations, only certain types of information among medical records are relevant for certain diagnoses. Medical records including images may therefore include a significant amount of data that is not actually relevant for a given use case. The disclosed embodiments, which include ways of efficiently reducing images using regions of interest, therefore can be utilized to reduce the among of data to be uploaded to a distributed electronic ledger such as a blockchain without utilizing a naive approach that simply reduces granularity of images or otherwise may cause loss of relevant data in exchange for data reduction.

[0035] Moreover, in order to increase the value of data, that data may be mined for diagnostic indicators. The disclosed embodiments, which include various techniques for image reduction, also enable identification of such diagnostic indicators which may be utilized in order to enrich medical records of the patient. These enrichments increase the certainty, timeliness, and accuracy of medical decisions (e.g., diagnoses and, consequently, treatment plans) made based on such medical records. As a result, the disclosed embodiments may also be utilized to enrich medical records in order to improve the medical and/or commercial value of those records.

[0036] Even further, allowing patients’ control over their medical data may enable new practical implementations using that medical data. More specifically, if a patient has access to their medical records through a wallet (i.e. , a device or program configured to access the patient’s records on a blockchain) such that the patient can access their medical records on-demand, new opportunities for leveraging a patient’s medical records as a form of identification may become possible. Moreover, the properties of many blockchain solutions which allow for anonymization of data and prevent unauthorized alteration of records can be leveraged in order to allow patients to securely upload and access their medical records for identification purposes.

[0037] In this regard, it has been identified that certain information which may be represented in medical records is unique among individuals. As a non-limiting example, dental records showing 3D images of a patient’s teeth or other 3D models of a patient’s teeth are unique to that patient (i.e., no other patient would have an identical set of teeth), so dental records including 3D dental scans can be utilized to uniquely identify an individual. To this end, the medical records including reduced images uploaded to decentralized storage as described herein enable storing those records on a blockchain, thereby further enabling new implementations where a patient accesses a blockchain in order to access their 3D dental images and present those images as a form of “dental passport” that is unique to that individual. [0038] The disclosed embodiments may be utilized to realize a distributed electronic warehouse of dental data or other medical data which may be accessed and/or controlled by individual users owning respective portions of that dental or medical data. For example, a patient or other user who has obtained permission from a patient may access and/or control the records stored in the distributed electronic warehouse. Accordingly, some aspects of the disclosed embodiments may facilitate a user transferring records to a medical service professional, a lawyer, or another relevant person as needed. Further, the disclosed embodiments may enable users to sell their own medical records, for example, to medical researchers, drug developers, or health insurance companies seeking data in order to utilize that data for research and development or risk assessment. In this regard, such a warehouse may enable patients to engage in a medical data marketplace and even get a recurrent income.

[0039] As noted above, a widespread distributed electronic warehouse storing medical data may ultimately require storing a large amount of data across many nodes such that the disclosed embodiments, which include techniques for image reduction, indexing, and utilizing reduced images to create transaction data, provide the technical improvements which may be utilized in order to make such a warehouse feasible given modem computing and networking constraints or otherwise to improve performance of such a warehouse and the systems interacting (either directly or indirectly) with the warehouse.

[0040] The terms of such a medical data marketplace may be enforced via a digital enforcement mechanism such as, but not limited to, a smart contract. Such a smart contract is a set of computer-executable instructions that is recorded on a blockchain or other distributed electronic ledger, and which may run on the peer nodes of the blockchain network in order to enforce rules related to transactions recorded on the blockchain. As a non-limiting example, such a smart contract may include instructions for providing access to transaction data which preserves anonymity of data, enforces restrictions on reselling data, ensures that payment is received before granting access to sold data, allows for revenue sharing between individuals in relation to the transaction data, combinations thereof, and the like. To this end, in accordance with various disclosed embodiments, a smart contract may be recorded on a distributed electronic ledger via one or more transactions, and the smart contract may be executed by the nodes of the decentralized network across which the electronic ledger is distributed.

[0041] Due to properties of blockchains and other decentralized ledgers which allow individuals to coordinate without trust between those individuals, storing medical records on a blockchain may allow for multiple independent parties who do not know or trust each other to securely share data, track data provenance, maintain audit logs, maintain data synchronization, comply with regulations, define permissions, and otherwise control the data stored on the blockchain. This, in turn, allows users to leverage their medical data for various uses discussed herein without requiring a trusted centralized authority to handle their medical data.

[0042] FIG. 1 shows an example network diagram 100 utilized to describe the various disclosed embodiments. In the example network diagram 100, a user device 120, a decentralized transaction creator 130, a plurality of databases 140 (hereinafter referred to individually as a database 140 and collectively as databases 140, merely for simplicity purposes), a decentralized network 150, and a medical service provider system 160 communicate via a network 110. The network 110 may be, but is not limited to, a wireless, cellular or wired network, a local area network (LAN), a wide area network (WAN), a metro area network (MAN), the Internet, the worldwide web (WWW), similar networks, and any combination thereof.

[0043] The user device (UD) 120 may be, but is not limited to, a personal computer, a laptop, a tablet computer, a smartphone, a wearable computing device, or any other device capable of sending medical data or requesting medical data be sent from a database. The user device 120 may further be capable of displaying medical records or portions thereof.

[0044] In accordance with various disclosed embodiments, the user device may include (as shown), communicate with (not shown in FIG. 1), or otherwise have access to a wallet 125. The wallet 125 is a device or program configured to access the decentralized network 150 in order to retrieve records. The wallet 125 may therefore serve as the mechanism by which the user accesses records stored via the decentralized network 150.

[0045] The decentralized transaction creator 130 is configured to perform one or more of the disclosed techniques for preparing transactions for recording on the distributed electronic ledger 155 and uploading those transactions to the decentralized network 150. More specifically, the decentralized transaction creator 130 is configured to create transactions including medical record data, references to medical record data, or both. Further, in accordance with various disclosed embodiments, the decentralized transaction creator 130 is configured to reduce images included among the medical record data with respect to regions of interest in order to reduce the computing and networking resources needed for purposes such as creating transactions, uploading transactions, creating blocks including the uploaded transactions, sending medical data for storage on external systems, combinations thereof, and the like.

[0046] The databases 140 may store data related to users such as, but not limited to, medical records. In accordance with various disclosed embodiments, the medical records include medical images such as, but not limited to, 3D dental scan images. The data stored in the databases 140 may be sent for storage via the decentralized network 150, or a reference to the data stored in the databases 140 may be uploaded to and recorded via the decentralized network 150, in order to allow the user to access such data via the decentralized network 150.

[0047] The databases 140 may be or may include databases operated by medical provider services (e.g., doctors’ offices, healthcare chains, etc.) and, therefore, may store data related to different patients. Accordingly, the medical records to be uploaded to the decentralized network 150 on behalf of the patient may be initially provided from a medical service provider via the medical service provider device 160 operated by that medical service provider and then made available to a patient (e.g., a patient who is a user of the user device 120). As a non-limiting example, a pointer to a location of the patient’s medical records stored in one of the databases 140 may be sent from the medical service provider device 160 to the user device 120.

[0048] Alternatively, the medical records to be uploaded to the decentralized network 150 may be sent directly from the medical service provider’s system to the distributed transaction creator 130 for transaction creation and uploading. In such implementations, consent from the patient (e.g., the user of the user device 120) may be required before sending data from the medical service provider to the distributed transaction creator 130. To this end, the user device 120 may further be configured to prompt the user of the user device 120 to consent to such data sending (e.g., by displaying a notification with an interactable icon corresponding to an agreement to consent to sending medical data on the user device 120 and receiving user inputs related to an interaction with the icon).

[0049] The decentralized network 150 includes multiple computing nodes (not separately depicted), each computing node storing a copy of a distributed electronic ledger 155. In accordance with various disclosed embodiments, distributed electronic ledger 155 may be a blockchain. In various embodiments, the records created by the distributed electronic ledgers creator may be stored on the distributed electronic ledger 155, thereby enabling the benefits of such blockchain use discussed herein. To this end, in some embodiments, the distributed transaction creator 130 may be configured to upload transactions to the decentralized network 150 as new distributed electronic ledger entries are created. The transactions uploaded to the distributed electronic ledger 155 may include the distributed electronic ledgers created by the distributed transaction creator 130.

[0050] In accordance with various disclosed embodiments, the distributed electronic ledger 155 created by the distributed transaction creator 130 and uploaded to the decentralized network 150 include reduced images created as described further below. Such reduced images may be created using image reduction techniques utilizing regions of interest as discussed below with respect to FIGS. 4-5.

[0051] FIG. 2 is a flowchart illustrating a method for storing medical records on a decentralized storage platform according to an embodiment. In an embodiment, the method is performed by the distributed transaction creator 130, FIG. 1.

[0052] At optional S210, a user is onboarded to a service for facilitating the decentralization of the user’s medical records. During the onboarding process, the user may register with a service to which the medical records will be provided. The onboarding may be performed via the distributed transaction creator 130, or in another implementation may be performed via a different system (e.g., a server dedicated to onboarding or otherwise a different server owned, operated, or otherwise used in coordination with the system performing the method of FIG. 2). Additionally, during the onboarding, the user may be provided a wallet (e.g., the wallet 125, FIG. 1) which will enable access to records stored on a distributed electronic ledger (e.g., the distributed electronic ledger 155, FIG. 1). [0053] At S220, data to be stored via a decentralized network (e.g., the decentralized network 150, FIG. 1) are obtained. In an example implementation, such data may be received from a user device (e.g., the user device 120, FIG. 1) or may be retrieved from a data source (e.g., one of the databases 140, FIG. 1). The location of the data and any required access credentials may be provided via a user device.

[0054] In accordance with various disclosed embodiments, the data includes medical records. Further, the medical records may include various medical images. As noted above, these images may be 3D scans or other 3D data structures which include a significant amount of data such that reducing these images may demonstrate exponential savings in computing and networking resources, particularly when those images are to be uploaded to multiple nodes of a decentralized network such as a blockchain network.

[0055] At S230, images among the data obtained at S220 are reduced. In an embodiment, the images are reduced at least with respect to regions of interest (ROIs) identified therein. Techniques for image reduction are described in more detail below with respect to FIGS. 4-5 and in the above-referenced US Provisional Patent Application No. 63/481 ,304, the contents of which are hereby incorporated by reference.

[0056] At S240, the data may be enriched. In an embodiment, the data may be enriched with indicators of potential conditions reflected therein (e.g., diagnostic indicators which may be utilized to diagnose those conditions). As a non-limiting example, the data may be enriched with diagnostic indicators or with conditions detected as described further below with respect to S440. Such enrichment data may increase medical certainty, timeliness, accuracy, and the usefulness of the medical records data to which the user will be provided control and/or access.

[0057] In some embodiments, S240 may further include adding a watermark to the data or a portion of the data. As a non-limiting example, the data may be watermarked with a non- fungible token (NFT) identifier that is uniquely associated with the data (i.e. , such that the NFT identifier corresponds to that data and only that data, not other data). To this end, S240 may further include assigning such a NFT identifier, for example based on an order of the current iteration in a series of iterations involving creation of NFTs based on medical data. Such watermarking may be utilized to guarantee the uniqueness of a NFT based on the data, particularly image data. This, in turn, may prevent unauthorized copying of the data via a mechanism that can be readily enforced.

[0058] In this regard, the blockchain on which the data is stored can serve as a record tracing back the origin of the data. That is, when a transaction including a patient’s data is recorded on the blockchain, a timestamp of the transaction may consequently indicate a time at which a NFT including the data was minted or otherwise when the data was first recorded on the blockchain. In some implementations, smart contracts running on the blockchain may include code that, when executed, may check data included in new transactions to be uploaded to the blockchain against data of prior transactions in order to determine whether another version of the new data has already been uploaded to treat subsequent versions of the same underlying patient data as invalid. Further, the smart contracts may deny sale of or otherwise granting of access to invalid transaction data, thereby providing a mechanism for enforcing authenticity requirements.

[0059] At S250, the data may be anonymized. In an embodiment, S250 may include, but is not limited to, utilizing one or more encryption techniques, removing personal identifying information (PH) from the data, both, and the like. Such personal identifying information may be included as data indicating information that may be utilized to identify the user such as, but not limited to, name, social security number, credit card number, home address, phone number, portions thereof, combinations thereof, and any other information which may individually or in combination with other information identify a user whose medical information is reflected in the transaction data. When processing medical data to be transmitted over networks, and in particular when that data is to be broadcast over a network of peer devices over which no central authority has control, anonymization of the medical data may be utilized in order to ensure that the user’s medical history is not linked to the user in the event of a data leakage.

[0060] At S260, one or more transactions are created based on the data including the reduced images. The transactions may be created using one or more applicable algorithms corresponding to the decentralized network to which the data is to be uploaded. Each transaction is a set of transaction data assigning ownership to a user such that recording the transaction on a distributed electronic ledger such as a blockchain effectively assigns ownership of the subject of the transaction to a particular user or set of users.

[0061] The transaction data included in the transaction may include, but is not limited to, the medical record data (including any reduced images or clinical indicators), a reference to the medical record data on an external system (i.e. , on a server or other system which is not a node on the decentralized network or as a logical component of one of the nodes of the decentralized network that is not utilized by the decentralized network), both, and the like. The reference to an external system may include, but is not limited to, a location pointer pointing to a location of the medical record data on the external system, access credentials needed to access the data on the external system, both, and the like.

[0062] Storing the medical record data or a portion thereof in an external system and including a reference to that medical record data as part of the transaction instead of the medical record data itself may further reduce use of computing and networking resources needed to create and transmit transactions by further reducing the total amount of transaction data that needs to be broadcast to a blockchain network and stored on nodes of the blockchain network even when the underlying medical record data is reduced as described herein. More specifically, the reference to the underlying medical record data will often include less total data than the medical record data itself, particularly when the medical record data includes images such as 3D scans. Thus, sending the medical record data to a limited set of external systems and broadcasting a transaction including a reference to that medical record data to a blockchain network including a higher number of nodes will reduce use of computing and networking resources as compared to broadcasting a transaction including the medical record data itself over the blockchain network.

[0063] When the transaction data includes a reference to an external system, S260 also includes sending the medical record data to an external system and obtaining the location of the medical record data in the external system. As noted above, medical record data including reduced images created as described herein requires fewer computing and networking resources to transfer, either to a single external system or to multiple nodes of a decentralized network. Thus, the disclosed embodiments allow for improving computer and networking performance related to storage of such medical records in a manner that makes them accessible to users via the decentralized network.

[0064] At S270, the transactions are uploaded to a decentralized network. In an embodiment, S270 includes broadcasting each transaction to nodes among the decentralized network. In other words, the transactions are broadcast to computers in a peer-to-peer network. In some blockchain networks, there is a fee for uploading transactions. To this end, S270 may further include paying any such fees, for example using cryptocurrency represented on the blockchain to which the medical records will be uploaded or on another blockchain.

[0065] Once the transactions are uploaded to nodes of the decentralized network at S270, each transaction may need to be verified prior to recording. To this end, each node performing such verification may apply a validation algorithm based on one or more validation rules that define the criteria for verifying a transaction. Such a validation algorithm may be or may include, but is not limited to, a proof-of-work or proof-of-stake algorithm. Once any required validation is completed, the validated transaction(s) are incorporated into a block (a set of data including one or more transactions) to be recorded on the distributed electronic ledger.

[0066] Further, in many blockchain algorithms, each block after the first block recorded on the blockchain is linked to a previous block by a hash. The hash may be, but is not limited to, a hash of the contents of the block. Each block may store a hash of its own contents as well as a hash of a previously stored block in the blockchain. When the data being included in transactions includes medical images, using the reduced images as described herein for transactions to be recorded on the blockchain further reduces the amount of data needed to be stored in each block, thereby conserving memory of nodes in the blockchain network.

[0067] In some embodiments, the medical records may be realized as non-fungible tokens (NFTs). Such a NFT may be a non-interchangeable unit of data associated with a digital asset. A NFT is a mechanism which can be used to provide unique ownership over a set of data. To this end, the uploading of the transaction to the decentralized network at S270 may be included as part of a NFT minting process to mint a new NFT including the medical record data, regions of interest, diagnostic indicators, portions thereof, combinations thereof, and the like. This may further facilitate user control over those records, i.e. , by bundling the user’s medical record data as a NFT, the user may be able to readily access the NFT (thereby accessing the medical data), may buy or sell access to medical records as discrete digital assets by buying or selling NFTs of such medical records, and the like. Further, the access to medical records may be revocable, thereby providing further control over patients’ medical data. Thus, realizing the medical record data as NFTs may enable new methods of democratizing and liberalizing of patient medical data as discussed above.

[0068] Moreover, medical records owned by a user may be split into discrete portions, and different NFTs may be created for different distinct portions such that different portions of the patient’s medical records may be sold or otherwise controlled separate from other portions of the patient’s medical records. Further, some NFTs may include some overlapping data with other NFTs. As a non-limiting example, one NFT may only include dental records, while another NFT may include a patient’s entire set of medical records including the dental records. This may allow, for example, a patient to sell their dental records separately from other medical records, or may allow a patient to only sell a portion of their dental records (e.g., a portion which is relevant for research purposes) but retain access to the full set of dental records (e.g., to share with a dental professional when the patient goes for examination or treatment, or to use as a dental passport).

[0069] Different NFTs may be subject to different restrictions on sharing, sale, access, use, or a combination thereof. To this end, multiple different smart contracts may be utilized for different NFTs or different portions of smart contracts may be applied to different NFTs in order to allow for customizing the access controls for the NFT which are enforced by those smart contracts when executed on the blockchain. Moreover, different NFTs may be uploaded to different blockchains (e.g., by bundling those NFTs in different transactions). This may be performed for purposes such as, but not limited to, subjecting different NFTs to different smart contracts previously existing on the different blockchains in order to enforce the terms of each NFT without needing to create a new smart contract.

[0070] Creating different portions of data as NFTs may also be utilized in order to facilitate conserving computer and networking resources, for example, by storing NFTs with larger amounts of data or that include less sensitive records on blockchain networks with fewer nodes or on blockchain networks using different validation algorithms (e.g., proof of work, proof of stake, etc.) that require fewer computing resources. As a non-limiting example, data including 3D images may be stored on blockchains requiring fewer networking resources per unit of data than text or other lower size data in order to reduce the amount of computing and networking resources needed to store that those portions of data on their respective blockchains, and the portions of data may be minted as NFTs in order to realize them as discrete portions of data.

[0071] At S280, access of the user to the distributed electronic ledger storing the transactions is established. In an embodiment, S280 includes providing data needed to access the relevant portion of the distributed electronic ledger to a wallet of the user. The wallet is a device or computer program configured to access a decentralized network in order to retrieve data stored on a distributed electronic ledger such as a blockchain. A wallet may be uniquely assigned to a user such that the wallet only corresponds to one user, which may be utilized in order to ensure that only the appropriate user is provided access to the medical records via the decentralized network. This may further be relevant when the medical records act as a form of identification, i.e. , such that other users cannot access the user’s medical records in order to steal that user’s identity.

[0072] FIG. 3 is a flowchart illustrating a method for utilizing medical records stored on a decentralized storage platform as identification according to an embodiment. In an embodiment, the method is performed by the user device 120, FIG. 1.

[0073] At optional S310, an onboarding process is performed. In an embodiment, the onboarding process may begin when a user interacts with a web browser or application displayed via their user device. The application may be a software application installed on the user device. The web browser may display a web page, e.g., a web page that the user found via the Internet or whose location was encoded into a scannable barcode (e.g., a QR code) scanned via the user device.

[0074] In various implementations, the onboarding process further includes obtaining consent from the user to share the user’s medical data. To this end, in an embodiment, S310 may further include displaying a notification or otherwise displaying an interactable screen on the user device. Such a notification or screen may include an interactable icon or other interactable component which, when interacted with (e.g., by clicking, touching, swiping, or another gesture), confirms the user’s agreement to consent to share their medical data. Such consent is typically important for legal or regulatory purposes and may therefore be required prior to sharing data with a decentralized transaction creator and broadcast to the decentralized network.

[0075] At optional S320, user data to be recorded via the decentralized network is obtained. The user data may include, but is not limited to, images, medical history forms, medical professional notes, charts, test results, combinations thereof, and the like. It should be noted that, in some embodiments, the user data to be recorded may not be obtained by the system performing the method of FIG. 3 and, instead, such user data may be sent directly from a data source (e.g., one of the databases 140 or the medical service provider device 160) to a system configured to upload transactions to a decentralized network as discussed herein (e.g., the decentralized transaction creator 130).

[0076] At optional S330, the user data is sent to be used for creating and recording transactions via the decentralized network. The user data may be sent, for example, to the decentralized transaction creator 130, FIG. 1. After the data is sent, the transaction may be validated and, once validated, recorded on a distributed electronic ledger such as a blockchain.

[0077] At S340, access to the distributed electronic ledger is obtained. Specifically, access is obtained for the distributed electronic ledger on which the user data is stored. In an example implementation, a wallet of the user device (e.g., the wallet 125, FIG. 1 or an external wallet device not shown in FIG. 1) may be provided information needed to access the relevant part of the distributed electronic ledger such as, but not limited to, an identifier of the location of the transaction including the data on the distributed electronic ledger, access credentials needed to access the relevant location of the distributed electronic ledger, both, and the like.

[0078] As noted above, in at least some implementations, the medical records owned by the user which are recorded as part of transactions on the distributed electronic ledger may be realized as non-fungible tokens (NFTs). Each NFT may be, but is not limited to, a set of medical records assigned to the patient on the distributed electronic ledger. The wallet of the user may track ownership of various NFTs by the user, and may allow the user to access data related to those NFTs on the distributed electronic ledger or create transactions involving those NFTs. [0079] At S350, a request to utilize the user’s medical records as identification (ID) is received. The request may be received, for example, via one or more user inputs through a user interface accessed while a computer program (e.g., an application) is executed on the user device. As a non-limiting example, the user may press a button displayed on a touch screen on their mobile device that corresponds to requesting a “dental passport,” where the dental passport includes providing a portion of dental scan images of the user’s teeth that uniquely identify the user.

[0080] At S360, the distributed electronic ledger is accessed in order to obtain the relevant portion of data containing the medical records to be used as identification or containing a reference to such medical records. As noted above, such access may be realized via a wallet installed on or otherwise communicating with the user device.

[0081] At S370, medical record data obtained via the access at S360 is provided for use as identification. In an embodiment, the medical record data may be displayed via a user device. In another embodiment, the medical record data may be sent to an account associated with the user (e.g., via an email sent to an email account associated with the user). The medical record data of the user may be displayed, for example, to a medical professional. As noted above, certain medical records such as dental scans may be unique to different patients, so those medical records may be used as a form of identification for patients when made accessible on-demand in this manner.

[0082] FIG. 4 is a flowchart 400 illustrating a method for image analysis using reduced images according to an embodiment. In an embodiment, the method is performed by the distributed transaction creator 130, FIG. 1.

[0083] At S410, one or more images to be processed are obtained. In various embodiment, the obtained images are three-dimensional (3D) images. In a non-limiting example implementation, the images may be Cone Beam Computed Tomography (CBCT) images. The images may be obtained, for example but not limited to, from a user device as part of an onboarding process or otherwise related to a request to store data via a decentralized network as discussed above.

[0084] At S420, the obtained images are analyzed. In an embodiment, S420 includes performing image reduction by reducing images with respect to regions of interest (ROIs) and analyzing feature vectors determined using the reduced images. The image reduction includes one or more techniques for reducing the total amount of size of the data included in a given image. For example, S420 may include reducing the image resolution, or a combination of using ROI windows and reducing the image resolution. In an embodiment, S420 at least includes identifying regions of interest and reducing the images with respect to the identified regions of interest. The regions of interest may be realized as, for example but not limited to, ROI windows which are subsets of the images. To this end, S420 includes detecting the ROIs, encoding features of the ROIs, and processing the ROIs in order to produce reduced images which include data related to the ROIs and excludes at least a portion of other data of the original versions of their respective images.

[0085] In an embodiment, the image reduction is performed as now described with respect to FIG. 5. FIG. 5 is a flowchart S420 illustrating a method for performing data reduction on images and analyzing the reduced images according to an embodiment.

[0086] At optional S505, a resolution of the image may be reduced. As noted above, reducing the resolution of a 3D image may provide significantly reduced processing during subsequent steps, and can provide cubically greater savings in processing power and storage.

[0087] At S510, global features are extracted from images to be reduced. In an embodiment, S510 includes applying an image analyzer configured to extract global features from the images. This global feature extraction may optionally be an initial analysis of the entire image (e.g., the original image or a reduced resolution version of the image generated as noted above with respect to S505) which requires fewer processing resources than a more in-depth analysis. In turn, the more advanced analysis that requires more processing resources is subsequently performed only on select portions of interest (i.e., portions corresponding to the regions of interest as described below).

[0088] Consequently, computing resources can be preserved by performing this less intensive analysis on the entire image and only performing the more intensive analyses on the regions of interest. Further, the more intensive analysis may be performed on the full (i.e., non-reduced) resolution portions of the image corresponding to the regions of interest in order to improve accuracy without requiring analyzing the entirety of the image in full resolution, thereby conserving processing power and memory. Portions of the full resolution image may be utilized for certain implementations such as, but not limited to, osteoporosis detection and grading. Moreover, the global features may be input to models configured to perform region of interest detection in order to improve the accuracy of detecting such regions of interest.

[0089] In some embodiments, the global features may be extracted by analyzing a low- resolution version of an image instead of a higher resolution version of the image. Alternatively, an unsupervised image processing method may be utilized with respect to the image in order to extract the global features in a process which requires fewer computing resources than a more advanced image processing method.

[0090] As a non-limiting example, the anatomical center of the human head may be detected and global features indicating such an anatomical center are extracted. For example, the anatomical center may be detected using unsupervised machine learning techniques, or may be detected using supervised machine learning. Further, such supervised learning may utilize a light-weight network configured to detect or extrapolate the anatomical center location, for example when the image is a partial image (e.g., only showing a maxilla part) and the anatomical center is located outside of the image area. Alternatively, an object detection or region proposal method using supervised machine learning may be utilized to detect the anatomical center when the anatomical center is located inside the image area. Such anatomical center coordinates may be utilized, for example, to provide positional encoding for implementations involving osteoporosis detection or for helping to detect regions of interest for implementations involving sleep apnea detection. As another non-limiting example, a head orientation may be detected and extracted as a global feature.

[0091] Such features related to positional encoding may be utilized in later processing steps in order to improve accuracy of results related to attention mechanisms (such as, but not limited to, transformer networks) by, for example, allowing those attention mechanisms to utilize the relative locations of extracted regions of interest with respect to each other and with respect to certain locations (e.g., the head center) in order to make higher level decisions. As a non-limiting example, a classifier may utilize information indicating which ROI windows belong to the vertebrae and which ROI windows are located in the mandibular region in order to improve accuracy of classification. The positional encoding provides a way to specify ROI window locations even if the number of ROI windows is not constant or when relevant portions of the body (e.g., certain parts of the head) are not shown in a given image.

[0092] At S520, regions of interest (ROIs) are detected within images. In an embodiment, S510 includes applying one or more machine learning models trained to detect regions of interest within images. More specifically, in an example implementation, the regions of interest are detected using a supervised machine learning model such as an object detection or region proposal method (e.g., You Only Look Once [YOLO], a region proposal network [RPN], etc.). In another example implementation, the regions of interest may be detected using an unsupervised machine learning model trained to perform tasks related to image thresholding or otherwise to identify interesting regions in samples. In an embodiment, S520 includes inputting each image, the global features extracted from each image at S510, or both, to the machine learning models.

[0093] The models to be utilized at S510 may depend on the types of images to be processed (e.g., 2D vs 3D images), the subjects of the images (e.g., a particular region of a human such as a mandible as opposed to a vertebra), the types of outputs to be determined (e.g., grading values or certain types of ROI classification labels like joint locations, vertebra locations, nose structures, airways, pathological features, etc.), combinations thereof, and the like. To this end, S520 may further include selecting the models to be utilized for detecting regions of interest based on an initial analysis of the images, the metadata of the images, inputs received with the images, a combination thereof, and the like.

[0094] In some embodiments, S520 may further include performing a more resourceintensive analysis on portions of the image corresponding to initially identified regions and performing the ROI detection again in order to determine whether the initial ROIs were false positives. In this regard, it is noted that more simple region detection techniques may produce a high rate of false positives, particularly when applied to reduced resolution images. Performing region detection iteratively in this manner allows for filtering out false positives while reducing the amount of data which needs to be analyzed using the more resource-intensive analysis.

[0095] At S530, ROI features of the regions of interest are encoded into ROI feature vectors. In an embodiment, S530 includes feeding a ROI window for each ROI into a ROI feature encoder. Each ROI window is a portion of an image showing the respective a region of interest which makes a subset of image data of the image. In a further embodiment, the ROI feature encoder is or includes a convolutional neural network adapted to convert a 3D ROI window into a feature vector. The result of the encoding is one or more ROI feature vectors for each ROI.

[0096] At S540, the regions of interest are processed. More specifically, S540 includes analyzing the ROI feature vectors. The regions of interest may be further processed based on the global features extracted at S510. In some embodiments, the result of the region of interest processing includes one or more output feature vectors including output features related to a particular use case, for example, feature vectors including features needed for classification, regression, or segmentation.

[0097] In an embodiment, S540 includes applying one or more ROI processing models which may include, but are not limited to, transformer networks or other region-attention techniques. In this regard, it is noted that some implementations may utilize combined analysis of multiple feature vectors in order to derive information needed for a particular use case, and that such transformer networks allow for implementing cross-attention mechanisms between region of interest portions of images which can be utilized to modify values or otherwise alter ROI feature vectors in order to change the meaning of the information represented in each ROI feature vector based on the contents of other ROI features (e.g., of other ROI feature vectors being cross-attention analyzed together).

[0098] In a further embodiment, the cross-attention mechanisms further include analyzing the positioning of regions of interest relative to the original image. To this end, the relative positions of different portions of the images may be added to the feature encoding (for example, at S530) and utilized at S540 in order to process the resulting ROI feature vectors.

[0099] At S550, features of the regions of interest are decoded. The decoding may be performed, for example, based on the results of the ROI processing, the global features extracted from the images (e.g., at S510), both, and the like. The result is an image effectively reconstructed into an original image format of the original image. When the image is a 3D image, this would mean that a 3D representation may be recreated using the features vectors. In an embodiment, such decoding back into an original image format is performed in order to yield an image-based (spatial) output for subsequent processing, for example when the subsequent processing includes automated segmentation or other processes that utilize images as inputs. As a non-limiting example, such automated segmentation may be utilized for purposes such as cyst or sinusitis detection and segmentation, skull bone segmentation, tooth detection and segmentation, and the like.

[00100] At optional S560, the regions of interest are analyzed based on the output feature vectors or the decoded feature vectors in order to adapt the feature dimensionality of the analyzed feature vectors into output values for an output value dimensionality corresponding to the use case.

[00101] In an embodiment, S560 includes applying one or more models to the respective vectors being analyzed at S560. For example, an output feature vector may be input to a classifier head, or a decoded feature vector is input to a segmentation head. The analysis performed at S560, and consequently the outputs provided by the models, may depend on the implementation. Non-limiting example outputs include, but are not limited to, score, estimation of the osteoporosis grade, cyst coordinates, sinusitis location, sinusitis classification, TMD joint location and TMD disorder classification, tooth location or absence, tooth condition classification, combinations thereof, portions thereof, and the like. These outputs may be subsequently analyzed in order to, for example, detect conditions, make decisions on prescribing treatments, both, and the like.

[00102] Returning to FIG. 4, at S430, the reduced images are analyzed. More specifically, the output values determined by analyzing feature vectors as described above with respect to FIG. 5 are analyzed in order to detect potential conditions indicated by those output values. To this end, S430 may include applying one or more condition detection rules defined with respect to certain types of output values as well as the values themselves.

[00103] At optional S440, one or more conditions may be detected based on the results of analyzing the reduced images. In an embodiment, S440 includes applying one or more condition detection rules to outputs of the analysis. The condition detection rules may be, but are not limited to, predetermined rules defining values of outputs corresponding to respective conditions such as medical conditions. For example, certain classifications, scores, combinations thereof, and the like, may correspond to different medical conditions (or lack thereof), and the condition detection rules may define this correspondence with respect to potential values which can be results of the analysis. As noted above, the detected conditions may be utilized for purposes such as, but not limited to, enriching the medical record data of a patient with information regarding potential medical conditions. The total amount of data of the reduced images may therefore be reduced as compared to the original data even after adding enrichment data, thereby conserving computing resources as compared to using the original data during subsequent processing.

[00104] At optional S450, one or more notifications may be generated. The generated notifications may include indications of the detected conditions to be utilized for subsequent treatment of the patient, for example, to aid in diagnosis and therefore in determining an appropriate treatment for a given medical condition. As a non-limiting example, based on results of analyzing the reduced images, a notification indicating a detected sleep apnea condition may be generated and sent to a user device (e.g., a user device of a user who was onboarded as discussed above). In that example, the notification may allow the user to provide the information about their sleep apnea condition to a doctor in order to aid the doctor in diagnosing the user with obstructive sleep apnea (OSA) and determining that an appropriate course of treatment for the user would include use of an oral appliance such that the doctor will refer the user for an oral appliance in order to treat the user. This information may further help democratize medical records and allow patients to have more control over their own medical records.

[00105] FIG. 6 is an example schematic diagram of a distributed transaction creator 130 according to an embodiment. The distributed transaction creator 130 includes a processing circuitry 610 coupled to a memory 620, a storage 630, and a network interface 640. In an embodiment, the components of the distributed transaction creator 130 may be communicatively connected via a bus 650.

[00106] The processing circuitry 610 may be realized as one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), Application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information.

[00107] The memory 620 may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read only memory, flash memory, etc.), or a combination thereof.

[00108] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in the storage 630. In another configuration, the memory 620 is configured to store such software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the processing circuitry 610, cause the processing circuitry 610 to perform the various processes described herein.

[00109] The storage 630 may be magnetic storage, optical storage, and the like, and may be realized, for example, as flash memory or other memory technology, compact diskread only memory (CD-ROM), Digital Versatile Disks (DVDs), or any other medium which can be used to store the desired information.

[00110] The network interface 640 allows the distributed transaction creator 130 to communicate with, for example, the user device 120, the databases 140, the decentralized network 150, and the like.

[00111] It should be understood that the embodiments described herein are not limited to the specific architecture illustrated in FIG. 6, and other architectures may be equally used without departing from the scope of the disclosed embodiments.

[00112] FIG. 7 is a diagram 700 illustrating storage of a distributed electronic ledger which may be utilized in accordance with various disclosed embodiments. In the diagram 700, user data may be uploaded as transactions to nodes 710-1 through 710-9 of a decentralized network, where each node is a computer storing a respective copy of a distributed electronic ledger 720 such as a blockchain. As noted above, the transactions uploaded to the nodes 710 may be utilized to create blocks of transactions, where the blocks are recorded on the distributed electronic ledger 720. Also noted above, the copies of the distributed electronic ledger 720 stored across the nodes 710 may include copies of a smart contract, which is a set of computer-executable instructions configured to enforce terms of agreements between users with respect to data stored on the distributed electronic ledger 720.

[00113] The data uploaded to the nodes 710 may include data entered or otherwise provided directly by a user (e.g., a user of the user device 120, FIG. 1) or by a medical service provider (e.g., a user of the medical service provider system 160). The user may benefit from such uploading by, for example, receiving convenient access to their data on the distributed electronic ledger 720, receiving payment for the ownership or use of their data, both, and the like. The medical service provider may upload data as a service to patients, may receive compensation for such uploading (e.g., by obtaining improved insurance benefits from an insurance company who insures the medical service provider or by receiving government compensation for providing certain data).

[00114] FIG. 8 is a data flow diagram 800 illustrating data being provided by a user and prepared for upload to a decentralized storage which may be utilized in accordance with various disclosed embodiments. In FIG. 8, a user of a user device 810 provides data to a transaction creator 820 in order to create transactions and to broadcast those transactions to nodes 830 of a decentralized network.

[00115] In accordance with various disclosed embodiments, the user may choose for their data to be anonymized. Specifically, the data stored via transactions on the nodes 830 may be stripped of all potential personally identifiable information (PH) which may identify the user of the user device 810 or otherwise the patient whose medical history is reflected in the medical records data uploaded to the decentralized network, thereby allowing the owner of that data (e.g., the user of the user device 810) to recognize and access their own data while simultaneously preventing a potential buyer from knowing the identity of the patients whose medical data will be purchased.

[00116] Additionally or alternatively, a function may be utilized in order to confirm authenticity of the data stored on the distributed electronic ledger via the nodes 830. As a non-limiting example, a computer program may require another trusted user (e.g., a doctor or a system configured to perform an automated watermark checking process) to confirm that the medical data is authentic without necessarily requiring any other information about the patient to whom that medical data is related. [00117] In some implementations, the user of the user device 810 may be provided with multiple ways to access the data stored on the nodes 830. As a non-limiting example, the user may be provided with multiple passwords, where different passwords may be provided to other users. Further some passwords or other access credentials may correspond to different access permissions, for example, where one password provides access to the entire set of medical data stored for a particular patient while another password only provides access to a relevant portion of the patient’s medical data (e.g., access to particular medical records being sold for research purposes but not the patient’s full medical history, or a set of medical data that uniquely identifies the data such as a “dental passport” but not other medical data).

[00118] FIG. 9 is a smart contract diagram 900 utilized to illustrate potential agreements between users which can be realized via one or more smart contracts recorded on a blockchain or other distributed electronic ledger. As illustrated in FIG. 9, users 910-1 through 910-3 encode terms of respective agreements into smart contracts 920-1 through 920-3. The smart contracts 920 automatically enforce terms of such agreements with respect to data stored on a distributed electronic ledger such as a blockchain.

[00119] Non-limiting examples of potential agreements realized via smart contracts are now described with respect to FIG. 9.

[00120] As a first non-limiting example, a smart contract 920-1 may encode terms of an agreement between the users 910-1 and 910-2 in which the user 910-1 sells their medical records stored on a blockchain to the user 910-2. The user 910-1 may further define terms to be enforced by the smart contract which place restrictions on reselling the data or provide a revenue sharing model by which both the user 910-1 and the user 910-2 receive revenue when the medical record data of the user 910-1 is subsequently sold or otherwise access to such data is paid for (e.g., by the user 910-3).

[00121] As a second non-limiting example, a smart contract 920-2 may encode terms of an agreement between the users 910-2 and 910-3 in which the user 910-2 grants limited access to a portion of the medical records data owned by the user 910-2 to the user 910- 3 (e.g., for research purposes). The smart contract 920-2 may further enforce terms related to preventing reselling of the medical records data by the user 910-3 or setting conditions for selling data (e.g., only to consumers who meet certain conditions). [00122] As a third non-limiting example, a smart contract 920-3 may encode terms of an agreement between the users 910-3 and 910-1 in which the user 910-3 grants permission of the user 910-1 access to the medical records data of the user 910-1 (e.g. , in which the user 910-1 is the patient who is the subject of the medical records data) after the user 910-3 has purchased the medical records data of the user 910-1. Such access may be utilized to allow the user 910-1 to, for example, share their medical records with medical professionals or use their medical records as a form of ID even after the user has sold their medical records data.

[00123] FIG. 10 is a diagram 1000 illustrating automated processing of user data which may be utilized in accordance with various disclosed embodiments. As shown in FIG. 10, data provided by a user via a user device 1010 may be analyzed, indexed, or otherwise processed in order to facilitate recording such data as part of a transaction on a distributed electronic ledger. As discussed above, the processing of the data may include detecting potential medical conditions of the patient who is the subject of the data, and the user of the user device 1010 may be notified of such detected potential medical conditions.

[00124] In some implementations, at least some of the data provided by the user may be utilized to automatically fill out one or more forms 1020.

[00125] FIG. 11 is a flow diagram 1100 illustrating user control activities with respect to medical data which may be utilized in accordance with various disclosed embodiments.

[00126] At 1110, a user may provide medical and/or dental records through one or more decentralized applications utilized by nodes of a decentralized network to which the user is granted access.

[00127] Through the access to the decentralized network, at 1120, the user may be provided with direct and/or easy access to their own medical and/or dental records.

[00128] At 1130, the user can optionally anonymize their medical and/or dental data, which in turn may make the data more suitable for purposes such as automating filling out forms and/or analysis of the data at 1140 or utilizing smart contracts to sell data at 1150. Through such smart contracts, revenue may optionally be split and received by the user who originally provided the data at 1160.

[00129] The data shared by the user at 1110 may be indexed or compiled with other data at 1170 for custom purposes such as, but not limited to, for particular research purposes. In turn, such indexed or compiled data may be put in a form that is suitable for consumers of such data (e.g., startups, researchers, hospitals, insurance companies, pharmaceutical companies, etc.) to purchase such data at 1180.

[00130] FIG. 12 is a flow diagram 1200 illustrating a process for a data marketplace which may be utilized in accordance with various disclosed embodiments.

[00131] As shown in FIG. 12, a data owner interface 1210 communicates with a decentralized database 1220, for example, via a decentralized network such as the decentralized network 150, FIG. 1. The data owner interface 1210 may communicate either directly or indirectly with the decentralized network on which the decentralized database 1220 is stored in order to perform activities such as, but not limited to, utilizing the data stored on the decentralized database 1220 for one or more automated programs, services, and/or forms 1230, defining one or more smart contracts 1240, creating an index 1250 of available data for users including the user of the data owner interface 1210, combinations thereof, and the like.

[00132] The smart contracts 1240, in turn, may be utilized to define and enforce terms of a data purchasing program 1260. Related to such a data purchasing program 1260 may be a revenue distribution program 1270, which may also be realized via the smart contracts 1240. For example, purchases made pursuant to the data purchasing program 1260 may also be subject to the revenue distribution program 1270 such that the data owner of the data owner interface 1210 may receive at least a portion of revenue as their data is sold or otherwise when access to their data generates revenue.

[00133] To facilitate sales, the smart contracts 1240 may communicate with a data buyer interface 1280 in order to implement the data purchasing program 1260. Further, the data buyer interface 1280 may interact with one or more automated programs, services, forms, and/or data filtering mechanisms.

[00134] FIG. 13 is an example illustration 1300 of a patent record system which may be utilized in accordance with various disclosed embodiments. As illustrated in FIG. 13, a set of records 1310 may be stored in a computer readable medium 1320.

[00135] The system may integrate medical, dental, insurance, financial, and/or social records. A combination of these kinds of records may be advantageous when, for example, a dental condition is due to non-dental medical intervention (for example, change of color due to use of tetracycline, abrasion due to use of nerve affecting drugs, dental conditions not caused due to medical history such as loss of bite due to non- medically caused abrasion and/or attrition of teeth, etc.).

[00136] The medical records may include, but are not limited to, X-Ray images (Periapical status, Panoramic and/or CT scan images), clinical images of the patient, 3D data (e.g., intra-oral scanning data), face, profile, smile, teeth in the bite, teeth relaxed, measurements (for example, measurements of the difference in the distance between various points), intraoral images (showing teeth from various sides, bites, arches, fold-to- fold pictures, etc.), combinations thereof, and the like. Snap shots may be included to show changes in teeth and/or facial appearance, for example, when there are breaks in the clinical record of these aspects. The records may also include records of a clinical examinations and/or observations, for example, a diagnostic sheet may be compiled and added to the records. In some embodiments, personal factors, complaints, insights, and requests of the patient may be included. In some embodiments, a history of medical interventions which may relate to dental condition may be included.

[00137] The records may further include dental data as a form of “dental passport.” The dental data making up such a dental passport may include, but is not limited to, dental images (e.g., images taken during dental scans), checkup records, patient chart records, anamnesis history, combinations thereof, and the like. A dental passport may be utilized as part of the dental history (anamnesis) and data collection for a given patient. In some embodiments, an aesthetic evaluation may be performed as part of the data gathering process.

[00138] Optionally, a patient’s medical (for example dental) records will be transferred and/or stored on a computer readable memory owned or used by the patient. For example, this may facilitate the patent getting a second opinion and/or checking if dental interventions were done properly or unnecessarily. For example, the records may be stored on a mobile memory (for example a memory of a mobile device such as a smartphone). Alternatively or additionally, the records may be available to the patient over a network. In some embodiments, the patient will have access to reader and/or viewer software by which he will be able to access and/or read his own records. [00139] FIGS. 14A-N are various examples of patient data which may be recorded on a decentralized storage in accordance with various disclosed embodiments.

[00140] FIG. 14A shows a set of patient data 1400A. The patient data 1400A includes notes made based on statements from the patient indicating potential symptoms and sensations experienced by the patient.

[00141] FIG. 14B shows a set of patient data 1400B. The patient data 1400B includes notes made based on a patient’s dental history including past diagnoses and treatments.

[00142] FIG. 14C shows a set of patient data 1400C. The patient data 1400C includes notes made based on a patient’s dental history including dental devices utilized by the patient as well as family history of the patient.

[00143] FIG. 14D shows a set of patient data 14000. The patient data 14000 includes notes on a patient’s medical history including other (non-medical) conditions the patient has previously been diagnosed with.

[00144] FIG. 14E shows a set of patient data 1400E. The patient data 1400E includes additional information on Parkinson’s disease which may be relevant given the patient’s medical, dental, and family history.

[00145] FIG. 14F shows a set of patient data 1400F. The patient data 1400F includes notes made based on a patient’s oral habits which might be relevant to potential dental conditions for the patient or otherwise serve as relevant context for medical records of the patient.

[00146] FIG. 14G shows a set of patient data 1400G. The patient data 1400G includes notes made based on a patient’s statements including concerns about potential effects of the patient’s dental conditions on the patient’s appearance and life.

[00147] FIG. 14H shows a set of patient data 1400H. The patient data 1400H includes notes made based on an oral examination involving observation of the patient’s mouth.

[00148] FIG. 141 shows a set of patient data 14001. The patient data 14001 includes additional notes made based on an oral examination involving observation of the patient’s mouth.

[00149] FIG. 14J shows a set of patient data 1400J. The patient data 1400J includes notes made based on an aesthetic examination of the patient’s smile and teeth. [00150] FIG. 14K shows a set of patient data 1400K. The patient data 1400K includes a medical professional’s summary of the patient’s medical condition and attitude based on observations of and interactions with the patient.

[00151] FIG. 14L shows a set of patient data 1400L. The patient data 1400L includes notes about potential dental affects for the patient given the patient’s current and predicted future dental condition.

[00152] FIG. 14M shows a set of patient data 1400M. The patient data 1400M includes a list of dental diagnoses for the patient.

[00153] FIG. 14N shows a set of patient data OON. The patient data MOON includes a prognosis determined for the patient based on the dental diagnoses for the patient.

[00154] It is noted that various disclosed embodiments are discussed with respect to medical records without limitation on the disclosure. Dental records or other kinds of records, particularly records which include images like 3D scans, may be equally applicable without departing from the scope of the disclosure.

[00155] It is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed embodiments. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.

[00156] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software may be implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal.

[00157] All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosed embodiment and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

[00158] It should be understood that any reference to an element herein using a designation such as “first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise, a set of elements comprises one or more elements.

[00159] As used herein, the phrase “at least one of’ followed by a listing of items means that any of the listed items can be utilized individually, or any combination of two or more of the listed items can be utilized. For example, if a system is described as including “at least one of A, B, and C,” the system can include A alone; B alone; C alone; 2A; 2B; 2C; 3A; A and B in combination; B and C in combination; A and C in combination; A, B, and C in combination; 2A and C in combination; A, 3B, and 2C in combination; and the like.