Managing the integration of medical devices into a computing platform

Abstract

The present disclosure relates to techniques for integrating medical devices into a digital health platform. In particular, aspects are directed to identifying subject data of a subject associated with a medical device, determining one or more parameters associated with administering a treatment to the subject using the medical device based on the subject data, sending a notification to a client device associated with the subject, receiving an authentication procedure from the client device associated with the subject, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device, verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject, and approving administration of the treatment to the subject in response to verifying the association.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 385,321, filed November 29, 2022, which is incorporated herein by reference in its entirety for all purposes. [Technical Field]

[0002] The present disclosure relates to digital and personalized healthcare, and in particular to techniques for managing the integration of medical devices into computing platforms. [Background technology]

[0003] In healthcare, medical devices undergo certification and validation processes to ensure compliance with regulations, such as those specified by the Food and Drug Administration (FDA) and the European Medicines Agency (EMA). Recently, software-as-a-medical-device (SAMD) applications have been developed to perform medical processes. SAMD applications can be used to provide medical images for display on a computing device, process medical data received or generated by the SAMD application, determine a subject's diagnosis, and so on. However, medical devices that include a SAMD application and provide treatment for a specific condition can be difficult to certify and validate if the medical device is used outside a clinical environment (e.g., at the subject's residence). Requiring the presence of a clinical professional to administer a treatment using a medical device can be inefficient for both the subject and the clinical professional. Therefore, advances are needed for medical devices that can administer treatment without the presence of a physician while remaining compliant with regulations. Summary of the Invention

[0004] Some embodiments of the present disclosure include a computer-implemented method for controlling a medical device, the computer-implemented method including: identifying subject data of a subject associated with the medical device; determining one or more parameters associated with administering a treatment to the subject using the medical device based on the subject data, the one or more parameters including a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and approving administration of the treatment to the subject in response to verifying the association.

[0005] In some embodiments, identifying the subject data involves receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.

[0006] In some embodiments, the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.

[0007] In some embodiments, the computer-implemented method further includes, before identifying the subject data, receiving an indication of registration of the medical device, generating a medical device authentication blockchain hash of the medical device, storing an association between the medical device authentication blockchain hash and the subject identifier, and injecting the medical device authentication blockchain hash into the medical device to authenticate the medical device.

[0008] In some embodiments, the computer-implemented method further includes receiving an authentication procedure by receiving a subject's login to a software application on a client device, the login including unique identification information of the subject, and the client device configured to transmit a client authentication blockchain hash in response to the login to the software application.

[0009] In some embodiments, the unique identifying information is a biometric identifier of the subject.

[0010] In some embodiments, verifying the association includes accessing a data store that includes multiple associations between multiple identifiers of multiple subjects and multiple blockchain hashes, and determining that the data store includes a subject identifier associated with the client authentication blockchain hash and the medical device authentication blockchain hash.

[0011] In some embodiments, the computer-implemented method further includes receiving a firmware update for the medical device from a remote computing system, scheduling transmission of the update to the medical device, and pushing the update to the medical device based on the scheduling.

[0012] In some embodiments, scheduling transmission of the update to the medical device includes scheduling the transmission for a time outside the time window.

[0013] In some embodiments, the computer-implemented method further includes determining that the medical device opts out of an update to the firmware after a predetermined period of time has passed since receiving the update, and in response to determining that the medical device opts out of the update, expiring a medical device authentication blockchain hash associated with the medical device to prevent additional administration of the procedure by the medical device.

[0014] Some embodiments of the present disclosure include a computer-implemented method for registering and expiring a medical device, the computer-implemented method including receiving an identifier of a medical device that includes software for administering a treatment to a subject; performing certification and verification procedures for the medical device; determining that the certification and verification procedures are successful for the medical device; registering the medical device as a trusted device for administering a treatment to a subject; associating a client device of the subject with the medical device; and assigning a client authentication blockchain hash to the client device to authenticate the client device and a medical device authentication blockchain hash to authenticate the medical device before administering a treatment to the subject.

[0015] In some embodiments, the computer-implemented method further includes receiving a firmware update for the medical device from a remote computing system, scheduling transmission of the update to the medical device, and pushing the update to the medical device based on the scheduling.

[0016] In some embodiments, scheduling the transmission of the update to the medical device includes scheduling the transmission for a time outside a time window for administering the treatment to the subject.

[0017] In some embodiments, the computer-implemented method further includes determining that the medical device opts out of an update to the firmware after a predetermined period of time has passed since receiving the update, and in response to determining that the medical device opts out of the update, expiring a medical device authentication blockchain hash associated with the medical device to prevent the medical device from administering the procedure.

[0018] In some embodiments, the computer-implemented method further includes receiving data indicating performance of the treatment is below a threshold, and in response to determining that the performance is below the threshold, expiring a medical device authentication blockchain hash associated with the medical device to prevent administration of the treatment by the medical device.

[0019] In some embodiments, the computer-implemented method further includes identifying subject data of a subject associated with a medical device; determining, based on the subject data, one or more parameters associated with administering a treatment to the subject using the medical device, wherein the one or more parameters include a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and approving administration of the treatment to the subject in response to verifying the association.

[0020] In some embodiments, identifying the subject data involves receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.

[0021] In some embodiments, the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.

[0022] In some embodiments, the computer-implemented method further includes storing an association between the medical device authentication blockchain hash and the subject's identifier, and injecting the medical device authentication blockchain hash into the medical device to authenticate the medical device.

[0023] In some embodiments, the computer-implemented method further includes receiving a subject's login to a software application on a client device, the login including unique identification information of the subject, and the client device configured to transmit a client authentication blockchain hash in response to the subject's login to the software application.

[0024] In some embodiments, the unique identifying information is a biometric identifier of the subject.

[0025] In some embodiments, verifying the association includes accessing a data store that includes multiple associations between multiple identifiers of multiple subjects and multiple blockchain hashes, and determining that the data store includes a subject identifier associated with the client authentication blockchain hash and the medical device authentication blockchain hash.

[0026] Some embodiments of the present disclosure include a system including one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium including instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium, the computer program product including instructions configured to cause one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein.

[0027] The terms and expressions which have been employed are used as terms of description rather than of limitation, and there is no intention in the use of such terms and expressions to exclude equivalents of the features shown and described or portions thereof, but it is recognized that various modifications are possible within the scope of the invention as claimed. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be resorted to by those skilled in the art, and that such modifications and variations are deemed to be within the scope of the invention as defined by the appended claims. [Brief explanation of the drawings]

[0028] The present disclosure is described in conjunction with the accompanying drawings, in which:

[0029] [Figure 1] FIG. 1 illustrates a diagram of a digital health platform for providing data-driven technology solutions, according to various embodiments.

[0030] [Figure 2] 1 shows a diagram of a model system according to various embodiments.

[0031] [Figure 3] FIG. 1 shows another view of a model system according to various embodiments.

[0032] [Figure 4] 1 shows a flowchart illustrating a process for controlling medical devices using a digital health platform.

[0033] [Figure 5] 1 shows a flowchart illustrating the process for enrolling and expiring a medical device on a digital health platform.

[0034] In the accompanying drawings, similar components and / or features may have the same reference label. Furthermore, various components of the same type may be distinguished by following the reference label with a dash and a second label that distinguishes between the similar components. If only a first reference label is used herein, the description is applicable to any one of the similar components having the same first reference label, regardless of the second reference label. DETAILED DESCRIPTION OF THE INVENTION

[0035] I. Overview The present disclosure describes techniques for integrating medical devices into a digital health platform. More specifically, embodiments of the present disclosure provide a digital and personalized healthcare platform that facilitates registering, managing, and expiring medical devices in a regulatory-compliant manner. While various embodiments are disclosed herein in which devices are developed to solve problems in the healthcare industry, it should be understood that these techniques can be implemented in other types of systems and settings. For example, these techniques can be implemented in the development of devices in many industries (such as finance, life sciences, supply chain, national security, law enforcement, public safety, etc.) where data sensitivity (e.g., whether it contains trade secrets or personal data about individuals) and device operation must meet regulatory standards.

[0036] A significant challenge in working with medical devices that administer treatments (e.g., injection devices, pill dispensers, etc.) is that a clinical professional, such as a physician, is often required to analyze a subject's data, determine the timing of the next administration of the treatment, schedule the subject's treatment, and perform the administration for the subject using the medical device. The clinical professional may need to oversee the administration of the treatment to ensure that the correct dose is administered to the correct subject. This makes the process time-consuming and involves the clinical professional and the subject being co-located at the time of administration. Additionally, the timing and amount of administration may be subject to inaccuracy during manual administration of the treatment.

[0037] To address these limitations and issues, the technology for integrating medical devices in the present disclosure utilizes a software as a medical device (SAMD) that is certified and verified in accordance with regulatory standards before integration and each use of the medical device. Thus, the medical device can be controlled by a digital health platform and administer a treatment to a subject after the medical device and SAMD have been certified and verified. The digital health platform can communicate with the subject's mobile device, which can then communicate with the medical device to integrate the medical device with the digital health platform. Thus, the digital health platform can analyze the subject's subject data, determine parameters for administering a treatment to the subject (e.g., dosage, timing, etc.), verify the identity of the subject receiving the treatment, and approve the administration of the treatment without the presence of a clinical expert. Thus, treatment can be administered efficiently and accurately at any time of day and in any location.

[0038] One exemplary embodiment of the present disclosure is directed to a method performed by a digital health platform that controls a medical device, the method including: identifying subject data of a subject associated with the medical device; determining, based on the subject data, one or more parameters associated with administering a treatment to the subject using the medical device, where the one or more parameters include a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and approving administration of the treatment to the subject in response to verifying the association.

[0039] Another exemplary embodiment of the present disclosure is performed by a digital health platform for registering and expiring medical devices, the digital health platform including receiving an identifier for a medical device including software for administering a treatment to a subject; performing certification and verification procedures for the medical device; determining that the certification and verification procedures are successful for the medical device; registering the medical device as a trusted device for administering a treatment to the subject; associating a client device of the subject with the medical device in response to registering the medical device; and assigning a client authentication blockchain hash to the client device to authenticate the client device and a medical device authentication blockchain hash to authenticate the medical device prior to administering a treatment to the subject.

[0040] II. Digital Health Platform FIG. 1 shows a simplified diagram of a digital health platform 100 for providing data-driven technology solutions, according to various embodiments. In the illustrated embodiment, the digital health platform 100 includes a client computing device 105 coupled to a cloud-based infrastructure 110 via a network 115 including a network gateway 120 and a network mesh 125. The infrastructure 110 is adapted to run services or software applications in service pods 130 using resources provisioned in a deployment ring 135 provisioned by a cloud service provider 140 (e.g., a distributed computing environment). These services or software applications may be provided to users of the client computing device 105 as web-based or cloud services, e.g., under an AaaS or SaaS model. Several providers, such as Amazon, Google, and Oracle, offer cloud services. The term cloud service is generally used to refer to services made available to users on demand over a communications network, such as the Internet, by a service provider's system (e.g., infrastructure 110), such as a government-regulated entity. Thus, consumers may use cloud services offered by a service provider without having to purchase separate licenses, support, or hardware and software resources supporting the service. For example, a cloud service provider's system may host one or more programs, and users may use the one or more programs on demand, over the Internet, without the user having to purchase infrastructure resources to run the one or more programs. Cloud services are designed to provide easy and scalable access to applications, resources, and services.

[0041] In some cases, a user (e.g., a software or service consumer) operating a client computing device 105 utilizes one or more client applications to consume software products, services, or systems provided by the various components 145 of the infrastructure 110. In other examples, a user (e.g., a developer) operating a client computing device 105 utilizes one or more client applications to upload source code for software products, services, or systems provided by the various components 145 of the infrastructure 110. The components 145 include software components that may be executed by one or more processors, hardware components, or combinations thereof. It should be understood that a variety of different system configurations are possible, which may differ from that depicted for the digital health platform 100. Thus, the embodiment depicted in FIG. 1 is an example of a distributed computing environment for implementing a digital health platform and is not intended to be limiting.

[0042] The client computing devices 105 include various types of computing systems, such as portable handheld devices, general-purpose computers such as personal computers and laptops, workstation computers, wearable devices, gaming systems, thin clients, various messaging devices, sensors or other sensing devices, etc. These computing devices may run a variety of mobile operating systems (e.g., Microsoft Windows Mobile (登録商標) Various types and versions of software applications and operating systems (e.g., Microsoft Windows, iOS, Windows Phone, Android, BlackBerry, Palm OS) are supported. (登録商標) , Apple Macintosh(登録商標) , UNIX (登録商標) or a UNIX-based operating system, Linux or a Linux-based operating system such as Google Chrome™ OS. Portable handheld devices include mobile phones, smartphones, (e.g., iPhones, (登録商標) ), tablets (e.g., iPad (登録商標) ), personal digital assistants (PDAs), etc. Wearable devices include Fitbit Versa (商標) Smartwatch, Magic Leap 1 (登録商標) and Oculus (登録商標) Gaming systems may include virtual reality (VR) or augmented reality (AR) systems such as the Kinect VR, VR- ... (登録商標) Microsoft Xbox with or without gesture input device (登録商標) game consoles, Sony PlayStation® systems, various game systems offered by Nintendo®, and others. Client device 105 may be capable of running a variety of different applications, such as various internet-related applications, communication applications (e.g., email applications, short message service (SMS) applications), and may use a variety of communication protocols.

[0043] Network 115 may be any type of network familiar to those skilled in the art that is capable of supporting data communications using any of a variety of available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk®, etc. By way of example only, network 115 may be a local area network (LAN), Ethernet, token ring, wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 suite of protocols, Bluetooth®, etc. (登録商標) , and / or any other wireless protocol), and / or any combination of these and / or other networks.

[0044] The network gateway 120 is a network node that forms a secure pathway between two or more of the networks 115 that operate on the same or different protocols. The network gateway 120 may provide network security using one or more of the following technologies: firewalls to monitor incoming and outgoing network traffic, virtual private networks to provide private, secure communication channels, security scans to identify security flaws in the network, access managers for authentication and authorization services, etc. The network gateway 120 routes network traffic using routers and service connectors that manage access to various software products, services, or systems (e.g., using a service subscription business model). The network mesh 125 is a local network topology in which the infrastructure 110 (e.g., bridges, switches, and other infrastructure devices) directly, dynamically, and non-hierarchically connect to as many other nodes as possible and cooperate with each other to efficiently route data between the devices and nodes. The network mesh 125 manages connectivity using one or more of techniques such as load balancing, product, service, or system discovery, network access, routing, and peering, traffic mirroring, etc. The network 115 , network gateway 120 , and network mesh 125 work in combination to manage all data flowing in and out of the infrastructure 110 .

[0045] Components 145 include one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, application-specific servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination of computers or systems operating individually or in combination to provide resources, data, services, or programs to client computing devices 105 over network 115. Components 145 may further include other computing architectures that involve virtualization, such as one or more virtual machines running virtual operating systems, or one or more flexible pools of logical storage that can be virtualized to maintain virtual storage. In various embodiments, components 145 are adapted to run one or more services or software applications that provide the functionality described in this disclosure.

[0046] Component 145 also includes one or more data repositories. These data repositories may, in various embodiments, be used to store data and other information. For example, one or more of the data repositories may be used to store information for providing data-driven technology solutions, such as software as a medical device (SAMD), and for validating and deploying source code to implement the data-driven technology solutions. The data repositories may reside in various locations. For example, a data repository used by a component may be local to the component or may be remote from the component and communicate with the component via a network-based or dedicated connection. The data repositories may be of different types. In particular embodiments, the data repository used by the component may be a database, such as a centralized database, a distributed database, a NoSQL database, a relational database, or the like. One or more of these databases may be adapted to enable storage, updating, and retrieval of data to and from the database in response to SQL-formatted commands. In particular embodiments, one or more of the data repositories may also be used by an application to store application data. The data repositories used by the applications may be of different types, such as, for example, a key-value store repository, an object store repository, or a general storage repository backed by a file system.

[0047] Components 145 also include computing nodes adapted to run one or more programs, such as services or software applications that provide the functionality described in this disclosure (e.g., services or software applications offered as web-based or cloud services, or applications for implementing a continuous integration and continuous deployment (CI / CD) system). Each node is a representation of a single machine, optionally implemented within a cluster of nodes. A single machine may be a physical machine (e.g., a server in a data center) or a service provider (e.g., a cloud service provider) with a set of available CPU and RAM resources. (商標) The infrastructure 110 may be a virtual machine hosted on a cloud provider such as AWS. In a cluster, nodes pool their resources to form a more powerful machine. When one or more programs are deployed on the cluster, the cluster intelligently handles distributing work to the individual nodes. As nodes are added or removed, the cluster can shift work as needed. Which individual machine actually runs the code is not important to the program(s) or to the infrastructure 110.

[0048] One or more programs deployed to one or more clusters are packaged as containers. Containers are a widely accepted standard, and various images can be defined for deploying one or more programs on the infrastructure 110. Containerization enables the infrastructure 110 to create self-contained execution environments. Any program and all of its dependencies can be packaged into a single file and then shared across the infrastructure 110. Container creation can be done programmatically, enabling a powerful, fully automated CI / CD pipeline used to validate and deploy code on the infrastructure 110. Containers are wrapped into higher-level constructs known as pods 130. Containers within the same pod 130 can share the same resources and local network. In some cases, containers can communicate with other containers within the same pod 130 as if they were on the same machine, while maintaining a degree of isolation from others. Pods 130 are used as the unit of replication within the infrastructure 110. When a program or resource becomes overwhelmed with processing and a single pod 130 instance cannot carry the load, the infrastructure 110 can be configured to deploy new replicas of the pod 130 in a cluster as needed. Even when not under heavy load, it can be beneficial to have multiple copies of the pod 130 running at any time in a production system to enable load balancing and fault tolerance. One or more instances of the pod 130 are provisioned in a cloud infrastructure system provided by one or more cloud service providers 140.

[0049] The cloud infrastructure system provided by one or more cloud service providers 140 includes infrastructure resources utilized to facilitate the provisioning of one or more instances of pods 130 that support various cloud services provided by infrastructure 110. To facilitate efficient utilization of these resources for provisioning one or more instances of pods 130, the resources may be bundled into a set of resources or resource modules (also referred to as a “deployment ring 135”). Each resource module or deployment ring 135 may include a pre-integrated and optimized combination of one or more types of resources. In certain examples, different deployment rings 135 may be pre-provisioned for different types of cloud services. For example, a deployment ring 135 for a SAMD service may be provisioned for the SAMD service, a deployment ring 135 for a data analytics service may include a different combination of resources than the deployment ring 135 in the SAMD service, may be provisioned for the data analytics service, and so on. For some cloud services, resources allocated to provisioning a service may be shared between services.

[0050] The digital health platform 100 further includes one or more kernels 150. The kernels 150 are adapted to run on each cloud infrastructure system provided by one or more cloud service providers 140. The kernels 150 are cluster managers that provide resource allocation and isolation across distributed applications or frameworks across the digital health platform 100. The kernels 150 provide an application programming interface (API) to one or more programs for orchestration of services and software, including resource management and scheduling. The kernel 150 architecture includes agent nodes for executing tasks, master nodes for sending tasks to agent nodes, a region manager for election and for looking up addresses of master nodes, and a framework for coordinating with master nodes to schedule tasks on agent nodes.

[0051] The digital health platform 100 further includes a CI / CD system 155. The CI / CD system 155 is implemented within a cloud infrastructure system, allowing the digital health platform 100 to frequently update, test, and distribute changes within the source code of a software product, service, or system. As described in detail herein, in healthcare, there are government regulations regarding data security (e.g., data integrity and data privacy) that software must comply with. In the CI / CD system 155, these policy regulations can be included in the code, allowing compliance to be automatically tracked, verified, and reconfigured. In the SAMD example, data storage locations, server access controls, and activity logging can be included in the source code to protect and manage user data during software use. Encryption and password-protected operations can further be included during continuous integration. During continuous distribution, security and monitoring tools can be used to track user activity and detect errors that may lead to security threats.

[0052] The CI / CD system 155 may also be used to provision models. Models are initially trained using a dataset, but over time, the model may drift or the data may change, necessitating an updated model. If the model runs within a software application, code associated with the software application may include triggers for when the model should be retrained. For example, the code may include instructions to retrain the model at predetermined time intervals, when new training data is available, or when the model's performance is determined to fall below a threshold. Additionally, software developers may explore variations in model architecture and hyperparameters in a test environment based on monitoring the model's performance in a production environment or based on estimated improvements for model optimization. The CI / CD system 155 allows for easy building, testing, and deployment to a production environment when the model is determined to meet performance requirements.

[0053] III. Model Systems 2-3 show simplified diagrams of model systems 200 / 300 for managing medical device registration, management, and expiration (including various components 145 of infrastructure 110 described in connection with FIG. 1) according to various embodiments. In the illustrated embodiment, model system 200 includes client devices 205 (e.g., personal computers, IoT devices, etc.), medical devices 210, servers 215, and remote systems 220. Server 215 represents various scalable instances of the components of infrastructure 110 described in connection with FIG. 1. Model system 200 also includes additional components 225, such as an administrator portal, a physician portal, and subject data endpoints.

[0054] The client device 205 and medical device 210 are actively or passively operated by a user and may generate and / or collect data in doing so (e.g., data (e.g., healthcare data) may be generated and / or collected from a SAMD application (e.g., SAMD application 305 of FIG. 3 ) running on the client device 205, or healthcare data may be generated and / or collected from a neuromodulation device implanted in the subject). In some examples, a software development kit associated with one or more applications on the client device 205 and / or medical device 210 is adapted to enable registering, enforcing, and expiring the subject's medical device 210. The subject may be a user associated with the client device 205 and medical device 210.

[0055] In some examples, the server 215 can receive an identifier for a medical device 210 that includes software for administering a treatment to a subject. The medical device 210 can be an injection device for injecting a dose of a medication into a subject. Alternatively, the medical device 210 can be a dispensing device for dispensing a dose of a medication to a subject. Other medical devices are possible. The identifier can uniquely correspond to the medical device 210.

[0056] The medical device 210 may be certified and verified before being trusted by the server 215 for use by a subject. Thus, the server 215 may perform certification and validation procedures for the medical device 210. The certification and validation procedures may each include one or more tests or operations that verify that the medical device 210 performs according to operational and security specifications. If the medical device 210 successfully completes the certification and validation procedures, the server 215 may register the medical device 210 as a trusted device for administering procedures. If the medical device 210 does not successfully complete one or both of the certification or validation procedures, the server 215 may prevent the medical device 210 from being registered as a trusted device.

[0057] Once the medical device 210 is registered, the server 215 can associate the medical device 210 with the client device 205. For example, a subject may receive the medical device and then access the SAMD application 305 on the client device 205. The subject may perform a registration process to associate the client device 205 with the medical device 210. For example, the subject may enter an identifier for the medical device 210 into an application that can send the identifier to the server 215, and the server 215 can verify that the identifier matches the identifier of the medical device 210 provided to the subject.

[0058] In addition to associating the medical device 210 with the client device 205, the server 215 can generate a unique identifier for each of the medical device 210 and the client device 205 so that the medical device 210 and the client device 205 can be authenticated before each administration of a procedure by the medical device 210. Each of the unique identifiers may be a blockchain hash. Thus, the server 215 can generate a client authentication blockchain hash assigned to the client device 205 and a medical device authentication blockchain hash assigned to the medical device 210. The client authentication blockchain hash can be injected into the client device 205, and the medical device authentication blockchain hash can be injected into the medical device 210. The server 215 can store an association between the subject identifier, the client authentication blockchain hash, and the medical device authentication blockchain hash. The association can be stored in a data store that includes an association of subject identifiers, client devices, and medical devices for multiple subjects.

[0059] Upon registering the medical device 210 and associating the medical device 210 with the client device 205, the server 215 can monitor the subject's subject data to determine parameters for administration of treatment. The subject data may be collected from one or more computing devices that monitor the subject's health attributes. For example, the server 215 may receive the subject data from one or more of the components 225. In some examples, the computing device may include a clinical device sensor and / or a handheld portable device. In one particular example, the computing device may be a wearable, such as a wristwatch, worn by the subject and monitoring the subject's heart rate and other health attributes.

[0060] The subject data may be input into one or more models that identify parameters associated with administering a treatment to a subject using the medical device 210. For example, the parameters may include a time window for administering the treatment, a dosage of the treatment, and other suitable parameters. The models may be machine learning models trained to receive the subject data and output parameter recommendations. The server 215 can then control the administration of the treatment to the subject according to the parameters.

[0061] As an example, during a time window identified for administration of the treatment, the server 215 can send a notification to the client device 205 indicating the time window to the subject. In response, the subject can perform an authentication procedure using the client device 205 during the time window so that the treatment can be administered. The authentication procedure may involve the subject logging in to the SAMD application 305 of the client device 205. In some examples, the login may include the subject providing unique identification information for the subject, such as a username and password, to access an account associated with the medical device 210. Additionally or alternatively, the unique identification information may be the subject's biometric identifier (e.g., fingerprint or facial identification). The server 215 can receive the login along with a client authentication blockchain hash associated with the client device 205. The server 215 may additionally receive an indication of a medical device authentication blockchain hash associated with the subject's medical device 210.

[0062] The server 215 can then verify the association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject. For example, the server 215 can perform a data store lookup to verify that the subject is associated with both the client authentication blockchain hash and the medical device authentication blockchain hash received during the authentication procedure. Upon verifying the association, the server 215 can approve administration of the treatment to the subject. For example, the server 215 can send an indication of approval either directly to the medical device 210 or to the client device 205. In response to the approval, the medical device 210 can perform the administration. The medical device 210 can automatically perform the administration based on receiving the approval, or the medical device 210 can receive additional instructions for administration after receiving the approval. For example, the server 215 can send instructions directly to the medical device 210 or to the client device 205, which then forwards the instructions to the medical device 210 to dispense the treatment.

[0063] The remote system 220 may be the developer of the medical device 210, and the remote system 220 may periodically generate updates to the firmware of the medical device 210. The digital health platform's server 215 may qualify and verify each update to ensure security and proper operation of the update before it is sent to the medical device 210. Once an update to the firmware is received and verified, the server 215 may schedule transmission of the update to the medical device 210. The server 215 may schedule transmission for a time that is outside of the time window in which a treatment is administered to a subject, so that the update does not interfere with the treatment. At the scheduled time, the server 215 may push the update to the medical device 210.

[0064] The medical device 210 may generate data, such as logs, regarding the administration of treatment and transmit the data to the server 215. The server 215 may process the data (e.g., clean, anonymize, de-identify, etc.) and then transmit the processed data to the remote system 220. Thus, the remote system 220 may receive data that can inform firmware updates or other developments without receiving confidential or other unnecessary information.

[0065] The server 215 may set a requirement that each medical device have a specific firmware version and remain registered as a trusted medical device. For example, the server 215 may specify that the medical device must be updated to the latest firmware version within a specific period (e.g., one week) of the server 215 receiving an update to the firmware. After the specific period has elapsed, the server 215 may determine that the medical device 210 does not contain the updated firmware. As a result, the server 215 may expire the medical device authentication blockchain hash associated with the medical device 210 so that treatments can no longer be managed by the medical device 210. The server 215 may simultaneously expire the blockchain hashes of all registered medical devices that do not contain the specified version of firmware.

[0066] Additionally or alternatively, medical devices may expire based on the performance of a treatment. For example, the server 215 may monitor the effectiveness or other performance of a treatment by periodically receiving data indicative of the effectiveness or performance. If performance falls below a threshold, the server 215 may expire the blockchain hash of any registered medical device administering the treatment. In this way, a subject may be prevented from receiving the treatment in substantially real time pending a determination of the treatment's degraded performance.

[0067] IV. Technologies for Integrating Medical Devices with Digital Health Platforms 4-5 illustrate processes and operations for integrating medical devices into a digital health platform. Individual embodiments may be described as a process depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or block diagram. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to the calling function or the main function.

[0068] The processes and / or operations illustrated in FIGS. 4-5 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processor cores), hardware, or a combination thereof. For example, as in the embodiment illustrated in FIGS. 1-3, the processes illustrated in FIGS. 4 and 5 may be executed by the digital health platform 100 and / or the model system 200 / 300 to control, expire, or register the medical device 210. The software may be stored in memory (e.g., on a memory device, a non-transitory computer-readable storage medium). The particular sequence of process steps in FIGS. 4-5 is not intended to be limiting. Other sequences of steps may be performed according to alternative embodiments. For example, in alternative embodiments, the steps outlined above may be performed in a different order. Furthermore, the individual steps illustrated in FIGS. 4-5 may include multiple sub-steps, which may be performed in various sequences as appropriate for the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0069] 4 shows a process 400 for controlling a medical device 210 using the digital health platform 100. In step 405, subject data for a subject associated with the medical device 210 is identified. The subject data may be received from one or more devices, such as the subject's sensor, wearable, physician computer system, or mobile device. The digital health platform 100 may receive the subject data.

[0070] In step 410, one or more parameters associated with administering a treatment to the subject are determined based on the subject data. The parameters may include a time window for administering the treatment. The subject data may be input into a machine learning model that outputs recommended parameters for administering the treatment to the subject.

[0071] In step 415, a notification is sent to the client device 205 (e.g., the subject's cell phone) indicating the time window. The notification may be sent before or during the time window to inform the subject of the upcoming administration of the treatment.

[0072] At step 420, an authentication procedure is received from the client device 205 during the time window. The authentication procedure may include a subject logging into an application on the client device 205 associated with the digital health platform 100. The subject may be required to provide unique identification information (e.g., biometric information) during the authentication procedure. As part of the authentication procedure, the client device may send a client authentication blockchain hash associated with the client device 205 and a medical device authentication blockchain hash associated with the medical device 210 to the digital health platform 100.

[0073] At block 425, the association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject is verified. The digital health platform 100 can access a data store containing the association between subject identifiers and blockchain hashes to determine whether the client authentication blockchain hash and the medical device authentication blockchain hash are associated with the subject. If it is determined that the subject is associated with the client authentication blockchain hash and the medical device authentication blockchain hash, the association is verified, meaning administration of the treatment can proceed.

[0074] In block 430, the administration of the treatment to the subject is approved. That is, the medical device 210 may be notified of the approval and may therefore carry out the administration of the treatment. Additionally or alternatively, the medical device 210 may be instructed to output the treatment once the association of the subject with the client device and medical device has been verified and the administration is approved. The administration of the treatment may be carried out according to the determined parameters to ensure the correct dosage and timing occurs.

[0075] 5 shows a process 500 for registering and expiring a medical device 210 with the digital health platform 100. In step 505, an identifier for the medical device 210 that includes software for administering a treatment to a subject is received. The identifier can uniquely correspond to the medical device 210.

[0076] In step 510, certification and validation procedures are performed on the medical device 210. The certification and validation procedures may each include one or more tests or operations that verify that the medical device 210 performs according to operational and security specifications.

[0077] The qualification and validation procedures are determined to be successful in step 515. The qualification and validation procedures may be successful if each test, a threshold number of tests, or a particular subset of tests produces the desired results for the medical device 210.

[0078] In step 520, the medical device 210 is registered as a trusted device for administering treatment to the subject. If the medical device 210 does not successfully complete one or both of the certification or validation procedures, the medical device 210 may be prevented from being registered as a trusted device and therefore may not be used to provide treatment.

[0079] In step 525, the subject's client device 205 is associated with the medical device 210. Upon receiving the medical device 210, the subject may access the SAMD application 305 on the client device 205 to associate the client device 205 with the medical device 210. The subject may perform a registration process using the SAMD application 305 to associate the client device 205 with the medical device 210. For example, the subject may enter an identifier for the medical device 210 into the SAMD application 305, which can send the identifier to the digital health platform 100, and the digital health platform 100 can verify that the identifier matches the identifier of the medical device 210 given to the subject.

[0080] In step 530, a client authentication blockchain hash is assigned to the client device 205, and a medical device authentication blockchain hash is assigned to the medical device 210. The client authentication blockchain hash can be used to authenticate the client device 205, and the medical device authentication blockchain hash can be used to authenticate the medical device 210 before a procedure is administered to a subject. The client authentication blockchain hash can be injected into the client device 205, and the medical device authentication blockchain hash can be injected into the medical device 210. The medical device authentication blockchain hash can expire at some point if the firmware of the medical device 210 does not meet requirements set by the digital health platform 100 or if the performance of the procedure falls below a threshold. Expiring the medical device authentication blockchain hash can prevent future administration of any procedure by the medical device 210. Thus, the digital health platform 100 can facilitate registering, managing, and expiring medical devices to provide for the approval and administration of procedures without the presence of a physician while remaining compliant with regulations.

[0081] V. Example As used below, any reference to a series of examples should be understood disjunctively as a reference to each of those examples (e.g., "Examples 1-4" should be understood as "Examples 1, 2, 3 or 4").

[0082] Example 1 is a computer-implemented method for controlling a medical device, the computer-implemented method including: identifying subject data of a subject associated with the medical device; determining, based on the subject data, one or more parameters associated with administering a treatment to the subject using the medical device, the one or more parameters including a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and approving administration of the treatment to the subject in response to verifying the association.

[0083] Example 2 is the computer-implemented method of Example 1, wherein identifying the subject data includes receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.

[0084] Example 3 is the computer-implemented method of Example 2, wherein the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.

[0085] Example 4 is the computer-implemented method of any of Examples 1-3, further including, before identifying the subject data, receiving an indication of registration of the medical device, generating a medical device authentication blockchain hash for the medical device, storing an association between the medical device authentication blockchain hash and the subject identifier, and injecting the medical device authentication blockchain hash into the medical device to authenticate the medical device.

[0086] Example 5 is the computer-implemented method of any of Examples 1-4, further including receiving an authentication procedure by receiving a subject's login to a software application on a client device, the login including unique identification information of the subject, and the client device configured to send a client authentication blockchain hash in response to the login to the software application.

[0087] Example 6 is the computer-implemented method of example 5, wherein the unique identifying information is a biometric identifier of the subject.

[0088] Example 7 is the computer-implemented method of any of Examples 1-6, wherein verifying the association includes accessing a data store that includes multiple associations between multiple identifiers of multiple subjects and multiple blockchain hashes, and determining that the data store includes the identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash.

[0089] Example 8 is a computer-implemented method described in any of Examples 1-7, further including receiving a firmware update for the medical device from a remote computing system, scheduling transmission of the update to the medical device, and pushing the update to the medical device based on the scheduling.

[0090] Example 9 is the computer-implemented method of Example 8, wherein scheduling transmission of the update to the medical device includes scheduling the transmission at a time outside the time window.

[0091] Example 10 is the computer-implemented method of Example 8, further including determining that the medical device opts out of updates to firmware after a predetermined period of time has passed since receiving the update, and in response to determining that the medical device opts out of the update, expiring a medical device authentication blockchain hash associated with the medical device to prevent additional administration of the procedure by the medical device.

[0092] Example 11 is a computer-implemented method for registering and expiring a medical device, the computer-implemented method including receiving an identifier for a medical device that includes software for administering a treatment to a subject; performing certification and verification procedures for the medical device; determining that the certification and verification procedures are successful for the medical device; registering the medical device as a trusted device for administering a treatment to the subject; associating a client device of the subject with the medical device; and assigning a client authentication blockchain hash to the client device to authenticate the client device and a medical device authentication blockchain hash to authenticate the medical device before administering the treatment to the subject.

[0093] Example 12 is the computer-implemented method of Example 11, further including receiving a firmware update for the medical device from a remote computing system, scheduling transmission of the update to the medical device, and pushing the update to the medical device based on the scheduling.

[0094] Example 13 is the computer-implemented method of Example 12, wherein scheduling transmission of the update to the medical device includes scheduling the transmission at a time outside a time window for administering the treatment to the subject.

[0095] Example 14 is the computer-implemented method of any of Examples 12-13, further including determining that the medical device opts out of an update to firmware after a predetermined period of time has passed since receiving the update, and in response to determining that the medical device opts out of the update, expiring a medical device authentication blockchain hash associated with the medical device to prevent the medical device from administering the procedure.

[0096] Example 15 is the computer-implemented method of any of Examples 12-14, further including receiving data indicating performance of the treatment is below a threshold, and in response to determining that the performance is below the threshold, expiring a medical device authentication blockchain hash associated with the medical device to prevent administration of the treatment by the medical device.

[0097] Example 16 is the computer-implemented method of any of Examples 11-15, further including: identifying subject data of a subject associated with a medical device; determining, based on the subject data, one or more parameters associated with administering a treatment to the subject using the medical device, where the one or more parameters include a time window for administering the treatment; sending a notification to a client device associated with the subject indicating the time window; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and approving administration of the treatment to the subject in response to verifying the association.

[0098] Example 17 is the computer-implemented method of Example 16, wherein identifying the subject data includes receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.

[0099] Example 18 is the computer-implemented method of Example 17, wherein the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.

[0100] Example 19 is the computer-implemented method of any of Examples 11-18, further including storing an association between the medical device authentication blockchain hash and the subject identifier, and injecting the medical device authentication blockchain hash into the medical device to authenticate the medical device.

[0101] Example 20 is the computer-implemented method of any of Examples 11-19, further including receiving an authentication procedure by receiving a subject's login to a software application on a client device, the login including unique identification information of the subject, and the client device configured to transmit a client authentication blockchain hash in response to the login to the software application.

[0102] Example 21 is the computer-implemented method of example 20, wherein the unique identifying information is a biometric identifier of the subject.

[0103] Example 22 is the computer-implemented method of Examples 16-21, wherein verifying the association includes accessing a data store that includes multiple associations between multiple identifiers of multiple subjects and multiple blockchain hashes, and determining that the data store includes an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash.

[0104] Example 23 is a system comprising one or more data processors and a non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods disclosed herein.

[0105] Example 24 is a computer program product tangibly embodied in a non-transitory machine-readable storage medium that includes instructions configured to cause one or more data processors to perform some or all of one or more of the methods disclosed herein.

[0106] VI. Further Considerations Some embodiments of the present disclosure include a system including one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium including instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium, the computer program product including instructions configured to cause one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein.

[0107] The terms and expressions which have been employed are used as terms of description rather than of limitation, and there is no intention in the use of such terms and expressions to exclude equivalents of the features shown and described or portions thereof, but it is recognized that various modifications are possible within the scope of the invention as claimed. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be resorted to by those skilled in the art, and that such modifications and variations are deemed to be within the scope of the invention as defined by the appended claims.

[0108] The following description provides only preferred exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of preferred exemplary embodiments will provide those skilled in the art with an enabling description for implementing various embodiments. It will be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.

[0109] In the following description, specific details are given to provide a comprehensive understanding of the embodiments. However, it will be understood that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

Claims

1. 1. A computer-implemented method for controlling a medical device, comprising: identifying subject data of a subject associated with the medical device; determining, based on the subject data, one or more parameters associated with administering a treatment to the subject using the medical device, wherein the one or more parameters include a time window for administering the treatment; sending a notification to a client device associated with the subject indicating the time window; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including a client authentication blockchain hash associated with the client device and a medical device authentication blockchain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and in response to verifying the association, authorizing administration of the treatment to the subject; 11. A computer-implemented method comprising:

2. identifying the target data, The computer-implemented method of claim 1 , comprising receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.

3. The computer-implemented method of claim 2 , wherein the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.

4. Before identifying the target data, receiving an indication of registration of the medical device; generating the medical device authentication blockchain hash of the medical device; storing the association between the medical device authentication blockchain hash and the subject's identifier; and injecting the medical device authentication blockchain hash into the medical device to authenticate the medical device; The computer-implemented method of claim 1 , further comprising:

5. 2. The computer-implemented method of claim 1, further comprising receiving the authentication procedure by receiving a login of the subject to a software application on the client device, the login including unique identification information of the subject, the client device being configured to transmit the client authentication block chain hash in response to the login to the software application.

6. The computer-implemented method of claim 5 , wherein the unique identification information is a biometric identifier of the subject.

7. Verifying the association includes: accessing a data store that includes a plurality of associations between a plurality of identifiers of a plurality of subjects and a plurality of blockchain hashes; and determining that the data store contains an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash; The computer-implemented method of claim 1 , comprising:

8. receiving a firmware update for the medical device from a remote computing system; scheduling transmission of the updates to the medical device; and pushing the updates to the medical device based on the scheduling; The computer-implemented method of claim 1 , further comprising:

9. Scheduling the transmission of the updates to the medical device includes: The computer-implemented method of claim 8 , further comprising scheduling the transmission for a time outside the time window.

10. determining that the medical device has rejected the update to the firmware after a predetermined period of time has elapsed since receiving the update; and In response to determining that the medical device has opted out of the update, expiring the medical device authentication blockchain hash associated with the medical device to prevent further administration of the procedure by the medical device; The computer-implemented method of claim 8 further comprising:

11. 1. A computer-implemented method for registering and expiring a medical device, comprising: receiving an identifier for a medical device that includes software for administering a treatment to a subject; performing qualification and validation procedures for said medical device; determining that the qualification procedure and the verification procedure are successful for the medical device; registering the medical device as a trusted device for administering the procedure to the subject; associating the target client device with the medical device; and assigning a client authentication blockchain hash to the client device to authenticate the client device and a medical device authentication blockchain hash to authenticate the medical device prior to administering the procedure to the subject; 11. A computer-implemented method comprising:

12. receiving a firmware update for the medical device from a remote computing system; scheduling transmission of the updates to the medical device; and pushing the updates to the medical device based on the scheduling; The computer-implemented method of claim 11 further comprising:

13. Scheduling the transmission of the updates to the medical device includes:

13. The computer-implemented method of claim 12, comprising scheduling the transmission for a time outside a time window for administering the treatment to the subject.

14. determining that the medical device has rejected the update to the firmware after a predetermined period of time has elapsed since receiving the update; and In response to determining that the medical device has opted out of the update, expiring the medical device authentication blockchain hash associated with the medical device to prevent the medical device from performing the procedure; The computer-implemented method of claim 12 further comprising:

15. receiving data indicating that performance of the treatment is below a threshold; and In response to determining that the performance is below the threshold, expiring the medical device authentication blockchain hash associated with the medical device to prevent the medical device from administering the procedure; The computer-implemented method of claim 12 further comprising:

16. identifying subject data for the subject associated with the medical device; determining, based on the subject data, one or more parameters associated with administering the procedure to the subject using the medical device, wherein the one or more parameters include a time window for administering the procedure; sending a notification to the client device associated with the subject indicating the time window; receiving an authentication procedure from the client device associated with the subject during the time window, the authentication procedure including the client authentication block chain hash associated with the client device and the medical device authentication block chain hash associated with the medical device; verifying an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject; and in response to verifying the association, authorizing administration of the treatment to the subject; The computer-implemented method of claim 11 further comprising:

17. identifying the target data, 17. The computer-implemented method of claim 16, comprising receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.

18. 20. The computer-implemented method of claim 17, wherein the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.

19. storing an association between the medical device authentication blockchain hash and the subject's identifier; and injecting the medical device authentication blockchain hash into the medical device to authenticate the medical device; The computer-implemented method of claim 11 further comprising:

20. 12. The computer-implemented method of claim 11, further comprising receiving a login of the subject to a software application on the client device, the login including a unique identification of the subject, the client device being configured to transmit the client authentication block chain hash in response to the login to the software application.

21. 21. The computer-implemented method of claim 20, wherein the unique identification information is a biometric identifier of the subject.

22. Verifying the association includes: accessing a data store that includes a plurality of associations between a plurality of identifiers of a plurality of subjects and a plurality of blockchain hashes; and determining that the data store contains an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash; 17. The computer-implemented method of claim 16, comprising:

23. 1. A system comprising: one or more data processors; a non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform a computer-implemented method according to any one of claims 1 to 22; and Including, the system.

24. 23. A computer program product tangibly embodied in a non-transitory machine-readable storage medium comprising instructions configured to cause one or more data processors to perform the computer-implemented method of any of claims 1 to 22.

Images