[go: up one dir, main page]

WO2024118431A1 - Gestion de l'intégration d'un dispositif médical dans une plateforme informatique - Google Patents

Gestion de l'intégration d'un dispositif médical dans une plateforme informatique Download PDF

Info

Publication number
WO2024118431A1
WO2024118431A1 PCT/US2023/080905 US2023080905W WO2024118431A1 WO 2024118431 A1 WO2024118431 A1 WO 2024118431A1 US 2023080905 W US2023080905 W US 2023080905W WO 2024118431 A1 WO2024118431 A1 WO 2024118431A1
Authority
WO
WIPO (PCT)
Prior art keywords
medical device
subject
computer
implemented method
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2023/080905
Other languages
English (en)
Inventor
Tomasz Albert WACINSKI
Abdesslem DRIDI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
F Hoffmann La Roche AG
Genentech Inc
Hoffmann La Roche Inc
Original Assignee
F Hoffmann La Roche AG
Genentech Inc
Hoffmann La Roche Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by F Hoffmann La Roche AG, Genentech Inc, Hoffmann La Roche Inc filed Critical F Hoffmann La Roche AG
Priority to KR1020257018887A priority Critical patent/KR20250116035A/ko
Priority to CN202380081586.6A priority patent/CN120303744A/zh
Priority to EP23828632.2A priority patent/EP4627592A1/fr
Publication of WO2024118431A1 publication Critical patent/WO2024118431A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/40—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user

Definitions

  • the present disclosure relates to digital and personalized healthcare, and in particular to techniques for managing integration of a medical device into a computing platform.
  • SAMD software as a medical device
  • SAMD applications may be used to provide medical images for display at a computing device, process medical data received or generated by the SAMD application, determine a diagnosis of a subject, and the like.
  • medical devices that include SAMD applications and provide treatment for a particular condition may be difficult to qualify and validate if the medical device is used outside of a clinical setting (e.g., at a residence of the subject). 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. Accordingly, there is a need for advances in medical devices that can administer a treatment without physician presence, while remaining compliant with regulations.
  • Some embodiments of the present disclosure include a computer-implemented method of controlling a medical device comprising: 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, wherein a parameter of the one or more parameters comprises a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving, from the client device associated with the subject, an authentication procedure during the time window, wherein the authentication procedure includes 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 an administration of the treatment to the subject in response to verifying the association.
  • 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 subj ect.
  • the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.
  • the computer-implemented method further involves, prior to identifying the subject data: receiving an indication of a registration of the medical device; generating the medical device authentication blockchain hash for the medical device; storing the association between the medical device authentication blockchain hash and an identifier of the subject; and injecting the medical device authentication blockchain hash into the medical device for authenticating the medical device.
  • the computer-implemented method further involves receiving the authentication procedure by receiving a login of the subject to a software application on the client device, wherein the login includes unique identification information of the subject, and wherein the client device is configured to send the client authentication blockchain hash in response to the login to the software application.
  • the unique identification information is a biometric identifier of the subject.
  • verifying the association involves accessing a datastore that includes a plurality of associations between a plurality of identifiers for a plurality of subjects and a plurality of blockchain hashes, and determining the datastore includes an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash.
  • the computer-implemented method further involves receiving, from a remote computing system, an update to firmware for the medical device, scheduling a sending of the update to the medical device, and pushing the update to the medical device based on the scheduling.
  • scheduling the sending of the update to the medical device involves scheduling the sending for a time outside of the time window.
  • the computer-implemented method further involves determining that the medical device excludes the update to the firmware subsequent to a predefined period of time passing since receiving the update, and in response to determining that the medical device excludes the update, expiring the medical device authentication blockchain hash associated with the medical device to prevent an additional administration of the treatment by the medical device.
  • Some embodiments of the present disclosure include a computer-implemented method of registering and expiring a medical device that involves: receiving an identifier of a medical device including software for administering a treatment to a subject; performing a qualification procedure and a validation procedure for the medical device; determining the qualification procedure and the validation procedure are successful for the medical device; registering the medical device as a trusted device for administering the 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 for authenticating the client device and a medical device authentication blockchain hash to the medical device for authenticating the medical device prior to administering the treatment to the subject.
  • the computer-implemented method further involves receiving, from a remote computing system, an update to firmware for the medical device, scheduling a sending of the update to the medical device, and pushing the update to the medical device based on the scheduling.
  • scheduling the sending of the update to the medical device comprises involves scheduling the sending for a time outside of a time window for administering the treatment to the subject.
  • the computer-implemented method further involves determining that the medical device excludes the update to the firmware subsequent to a predefined period of time passing since receiving the update and in response to determining that the medical device excludes the update, expiring the medical device authentication blockchain hash associated with the medical device to prevent an administration of the treatment by the medical device.
  • the computer-implemented method further involves receiving data indicating a 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 an administration of the treatment by the medical device.
  • the computer-implemented method further involves identifying subject data of the subject associated with the medical device; determining one or more parameters associated with administering the treatment to the subject using the medical device based on the subject data, wherein a parameter of the one or more parameters comprises a time w indow for administering the treatment; sending a notification indicating the time window to the client device associated with the subject; receiving, from the client device associated with the subject, an authentication procedure during the time window, w herein the authentication procedure includes the client authentication blockchain hash associated with the client device and the 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 an administration of the treatment to the subject in response to verifying the association.
  • 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 subj ect.
  • the one or more computing devices include a clinical device sensor, a handheld portable device, or a combination thereof.
  • the computer-implemented method further involves storing an association between the medical device authentication blockchain hash and an identifier of the subject and injecting the medical device authentication blockchain hash into the medical device for authenticating the medical device.
  • the computer-implemented method further involves receiving a login of the subject to a software application on the client device, wherein the login includes unique identification information of the subject, and wherein the client device is configured to send the client authentication blockchain hash in response to the login to the software application.
  • the unique identification information is a biometric identifier of the subject.
  • verifying the association involves accessing a datastore that includes a plurality of associations between a plurality of identifiers for a plurality of subjects and a plurality of blockchain hashes and determining the datastore includes an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash.
  • Some embodiments of the present disclosure include a system including one or more data processors.
  • the system includes a non-transitory computer readable storage medium containing instructions which, when executed on the one or more data processors, cause the one or more data processors to perform part or all of one or more methods and/or part or all of one or more processes disclosed herein.
  • Some embodiments of the present disclosure include a computer-program product tangibly embodied in anon- transitory machine-readable storage medium, including instructions configured to cause one or more data processors to perform part or all of one or more methods and/or part or all of one or more processes disclosed herein.
  • FIG. 1 depicts a diagram of a digital health platform for providing data-driven technology solutions according to various embodiments
  • FIG. 2 depicts a diagram of a model system according to various embodiments
  • FIG. 3 depicts another diagram of a model system according to various embodiments
  • FIG. 4 depicts a flowchart illustrating a process for controlling a medical device using a digital health platform
  • FIG. 5 depicts a flowchart illustrating a process for registering and expiring a medical device with a digital health platform.
  • the present disclosure describes techniques for integrating a medical device into a digital health platform. More specifically, embodiments of the present disclosure provide a digital and personalized healthcare platform that facilitates registration, control, and expiration of medical devices in a regulatory-compliant manner. It should be appreciated that although various embodiments are disclosed herein in which devices are developed to solve problems in the health care industry, 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 (financial, life sciences, supply chain, national security, law enforcement, public safety, etc.) in which the sensitivity of the data (whether it contains trade secrets or private data about individuals, for example) and operation of the devices needs to satisfy defined standards.
  • a significant challenge when dealing with medical devices that administer treatment is that a clinical professional, such as a physician, is often required to analyze a subject's data, determine a timing of a next administration of the treatment, schedule the treatment with the subject, and perform the administration for the subject using a medical device.
  • the clinical professional may need to oversee the administration of the treatment to ensure the correct dosage is administered to the correct subject.
  • dosage timing and amounts may be susceptible to inaccuracies during manual administration of a treatment.
  • the techniques for integrating a medical device in the present disclosure utilize software as a medical device (SAMD) that is qualified and validated according to regulatory standards prior to integration and before each use of the medical device.
  • SAMD software as a medical device
  • the medical device may be controllable by a digital health platform to perform an administration of a treatment to a subject after the medical device and SAMD are qualified and validated.
  • the digital health platform may communicate with a mobile device of the subject, which can in turn communicate with the medical device to integrate the medical device with the digital health platform.
  • the digital health platform can analyze subject data for a subject, determine parameters (e.g., dosage, timing, etc.) for an administration of treatment for the subject, verify an identify of the subject receiving the treatment, and approve the administration of the treatment without the clinical professional being present. So, the treatment may be administered efficiently and accurately at any time of day and in any location.
  • parameters e.g., dosage, timing, etc.
  • One illustrative embodiment of the present disclosure is directed to a method carried out by a digital health platform for controlling a medical device that includes: 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, wherein a parameter of the one or more parameters comprises a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving, from the client device associated with the subject, an authentication procedure during the time window, wherein the authentication procedure includes 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 an administration of the treatment to the subject in response to verifying the association.
  • Another illustrative embodiments of the present disclosure is directed to a method carried out by a digital health platform for registering and expiring a medical device that includes: receiving an identifier of a medical device including software for administering a treatment to a subject; performing a qualification procedure and a validation procedure for the medical device; determining the qualification procedure and the validation procedure are successful for the medical device; registering the medical device as a trusted device for administering the treatment to the subject; in response to registering the medical device, associating a client device of the subject with the medical device; and assigning a client authentication blockchain hash to the client device for authenticating the client device and a medical device authentication blockchain hash to the medical device for authentication of the medical device prior to administering the treatment to the subject.
  • FIG. 1 depicts a simplified diagram of a digital health platform 100 for providing data-driven technology solutions in accordance wdth various embodiments.
  • digital health platform 100 includes client computing devices 105 coupled to a cloud based infrastructure 110 via a network(s) 115 including network gateway 120 and network mesh 125.
  • the infrastructure 110 is adapted to execute services or software applications within service pods 130 using resources provisioned within placement rings 135 provisioned by cloud service providers 140 (e.g., a distributed computing environment).
  • cloud service providers 140 e.g., a distributed computing environment.
  • These services or software applications may be offered as web-based or cloud services, such as under an AaaS or SaaS model to users of client computing devices 105.
  • cloud service providers offer cloud services such as Amazon, Google, and Oracle.
  • cloud service is generally used to refer to a service that is made available to users on demand and via a communication network such as the Internet by systems (e.g., infrastructure 110) of a service provider such as a government regulated entity. Consumers may thus avail themselves of cloud services provided by a service provider without having to purchase separate licenses, support, or hardware and software resources that support the services.
  • a cloud service provider's system may host the one or more programs, and a user may, via the Internet, on demand, use the one or more programs without the user having to buy infrastructure resources for executing the one or more programs.
  • Cloud sen ices are designed to provide easy, scalable access to applications, resources and services.
  • users e.g., software or service consumers
  • client computing devices 105 utilize one or more client applications to consume the software products, services, or systems provided by various components 145 of the infrastructure 110.
  • users e.g., developers
  • client computing devices 105 utilize one or more client applications to upload source code for the software products, sendees, or systems to be 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 appreciated that various different system configurations are possible, which may be different from those illustrated for the digital health platform 100.
  • the embodiment shown in FIG. 1 is thus one example of a distributed computing environment for implementing a digital health platform and is not intended to be limiting.
  • 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, and the like. These computing devices may run various types and versions of software applications and operating systems (e.g.. Microsoft Windows®, Apple Macintosh®, UNIX® or UNIX-like operating systems, Linux or Linux-like operating systems such as Google ChromeTM OS) including various mobile operating systems (e.g., Microsoft Windows Mobile®, iOS®, Windows Phone®. AndroidTM, BlackBerry®, Palm OS®).
  • Portable handheld devices may include cellular phones, smartphones, (e.g., an iPhone®), tablets (e.g., iPad®), personal digital assistants (PDAs), and the like.
  • Wearable devices may include Fitbit VersaTM smart watch, virtual reality (VR) or augment reality (AR) systems such as magic leap 1® and Genius", and other devices.
  • Gaming systems may include various handheld gaming devices.
  • Internet-enabled gaming devices e g., a Microsoft Xbox® gaming console with or without a Kinect® gesture input device, Sony PlayStation® system, various gaming systems provided by Nintendo®, and others
  • the client devices 105 may be capable of executing various different applications such as various Internet-related apps, communication applications (e.g., E-mail applications, short message service (SMS) applications) and may use various communication protocols.
  • SMS short message service
  • Network(s) 1 15 are any type of network familiar to those skilled in the art that can support data communications using any of a variety of available protocols, including without limitation TCP/IP (transmission control protocol/Intemet protocol), SNA (systems network architecture). IPX (Internet packet exchange), AppleTalk®, and the like.
  • TCP/IP transmission control protocol/Intemet protocol
  • SNA systems network architecture
  • IPX Internet packet exchange
  • AppleTalk® AppleTalk®
  • network(s) 115 can be a local area network (LAN), networks based on Ethernet, Token-Ring, a 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 infra-red network, a wireless network (e.g., a network operating under any of the Institute of Electrical and Electronics (IEEE) 1002.11 suite of protocols, Bluetooth®, and/or any other wireless protocol), and/or any combination of these and/or other networks.
  • LAN local area network
  • WAN wide-area network
  • VPN virtual private network
  • PSTN public switched telephone network
  • PSTN public switched telephone network
  • IEEE Institute of Electrical and Electronics
  • the network gateway 120 is a network node that forms a secure passage between two or more of the networks 115 operating in the same or different protocols.
  • the network gateway 120 may provide network security using one or more of the following techniques: a firewall for monitoring incoming and outgoing network traffic, a virtual private network to provide private secure channels of communication, security scanning for identify ing security flaws within the network(s), an access manager for authentication and authorization services, and the like.
  • the network gateway 120 routes network traffic using a router and a service connecter that manages 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) connect directly, dynamically and non-hierarchically to as many other nodes as possible and cooperate with one another to efficiently route data between devices and nodes.
  • the network mesh 125 manages connections using one or more of the following techniques: load balancing, products, services, or systems discovery 7 , network access, routing, and peering, traffic mirroring, and the like.
  • the network(s) 11 , network gateway 120, and network mesh 125 work in combination to manage all data that inflows or outflows from infrastructure 110.
  • the components 145 include one or more general purpose computers, specialized 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 appropriate arrangement and/or combination computers or systems that work individually or in combination to provide resources, data, services, or programs to client computing devices 105 over network(s) 115.
  • the components 145 may further include one or more virtual machines running virtual operating systems, or other computing architectures involving virtualization such as one or more flexible pools of logical storage devices that can be virtualized to maintain virtual storage devices.
  • the components 145 are adapted to run one or more services or software applications that provide the functionality described in the present disclosure.
  • the components 145 also include one or more data repositories. These data repositories may be used to store data and other information in various embodiments. For example, one or more of the data repositories may be used to store information for providing data-driven technology 7 solutions such as software as a medical device (SAMD) and store information for validation and deployment of source code to implement the data-driven technology solutions.
  • SAMD software as a medical device
  • the data repositories may reside in a variety 7 of locations. For example, a data repository used by a component may be local to of the component or may be remote from the component and in communication with the component via a network-based or dedicated connection. Data repositories may be of different ty pes.
  • a data repository 7 used by a component may be a database, for example, a centralized database, a distributed database, a NoSQL database, a relational database, or the like.
  • a database for example, 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, update, and retrieval of data to and from the database in response to SQL-formatted commands.
  • one or more of data repositories may also be used by applications to store application data.
  • the data repositories used by applications may be of different types such as, for example, a key-value store repository, an object store repository, or a general storage repository supported by a file system.
  • the components 145 also include computing nodes adapted to run one or more programs such as services or software applications (e.g., the services or software applications offered as web-based or cloud sendees or the applications for implementing a continuous integration and continuous deployment (CI/CD) system) that provide the functionality described in the present disclosure.
  • Each node is a representation of single machine optionally implemented within a cluster of nodes.
  • the single machine may be a physical machine (e g., a server in a datacenter) or a virtual machine hosted on a cloud provider such as Amazon Web ServicesTM (AWS) with a set of a set of CPU and RAM resources that can be utilized.
  • AWS Amazon Web ServicesTM
  • the nodes pool together their resources to form a more powerful machine.
  • the cluster intelligently handles distributing work to the individual nodes. If any nodes are added or removed, the cluster can shift around work as necessary. It does not matter to the one or more programs, or the infrastructure 110, which individual machines are actually running the code.
  • the one or more programs deployed onto one or more clusters are packaged as containers.
  • Containers are a widely accepted standard, and various images can be defined for deploying the one or more programs on the infrastructure 110.
  • Containerization allows for the infrastructure 110 to create self-contained execution environments. Any program and all its dependencies can be bundled up into a single file and then shared on the infrastructure 110. Creating a container can be done programmatically, allowing for powerful fully automated CI/CD pipelines to be used for validating code and deployment of code on the infrastructure 110.
  • the containers are wrapped into a higher-level structure known as the pod 130. Containers in the same pod 130 may share the same resources and local network.
  • containers can communicate with other containers in the same pod 130 as though they were on the same machine while maintaining a degree of isolation from others.
  • the pods 130 are used as the unit of replication in the infrastructure 110. If programs or resources become overwhelmed with processing and a single pod 130 instance cannot carry the load, the infrastructure 1 10 may be configured to deploy new replicas of a pod 130 to the cluster as necessary'. Even when not under heavy load, it may be beneficial to have multiple copies of a pod 130 running at any time in a production system to allow load balancing and failure resistance.
  • the one or more instances of the pods 130 are provisioned on the cloud infrastructure system provided by the one or more cloud service providers 140.
  • the cloud infrastructure system provided by the one or more cloud service providers 140 include infrastructure resources that are utilized for facilitating the provision of the one or more instances of the pods 130 supporting various cloud services offered by infrastructure 110.
  • the resources may be bundled into sets of resources or resource modules (also referred to as "placement rings 135").
  • Each resource module or placement ring 135 may comprise a pre-integrated and optimized combination of resources of one or more types. In certain examples, different placement rings 135 may be pre-provisioned for different types of cloud services.
  • SAMD service placement rings 135 may be provisioned for a SAMD service
  • data analytics service placement rings 135, which may include a different combination of resources than placement rings 135 in the SAMD service placement rings 135. may be provisioned for data analytics service, and the like.
  • the resources allocated for provisioning the services may be shared between the sendees.
  • 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 the 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 entire digital health platform 100.
  • the kernels 150 provide the one or more programs with application programming interfaces (APIs) for orchestration of sendees and software including resource management and scheduling.
  • APIs application programming interfaces
  • the architecture of the kernels 150 includes agent nodes for running tasks, master nodes for sending task to the agent nodes, a zookeeper for elections and for looking up address of master nodes, and frameworks to co-ordinate with the master nodes to schedule tasks onto agent nodes.
  • the digital health platform 100 further includes a CI/CD system 155.
  • the CI/CD system 155 is implemented within the cloud infrastructure system and alloyvs the digital health platform 100 to frequently update, test, and deliver changes within source code for the software products, sendees, or systems.
  • these policy regulations can be included in the code, allowing compliance to be tracked, validated, and reconfigured automatically.
  • data storage locations, server access controls, and activity logging can be included in the source code, such that user data can be protected and managed throughout use of the software.
  • Encryption and password-protected operations can additionally be included during continuous integration. During continuous delivery, security and monitoring tools can be used to track user activity and detect errors that could lead to a security threat.
  • the CI/CD system 155 may also be used for provisioning models.
  • the models are initially trained using a dataset, but over time, the models may drift or the data may change, leading to a need for an updated models.
  • code associated with the software application can include triggers for when the models should be retrained.
  • the code may include instructions for the model to be retrained at predefined time intervals, when new training data is available, or when the performance of the model is determined to fall below a threshold.
  • software developers may explore variations in model architectures and hyperparameters in a testing environment based on monitoring the performance of the model 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.
  • FIGS. 2-3 depict simplified diagrams of model systems 200/300 (including the various components 145 of the infrastructure 110 described with respect to FIG. 1) for managing registration, administration, and expiration of a medical device in accordance with various embodiments.
  • model system 200 includes client device 205 (e.g., a personal computer, loT device, or the like), a medical device 210, server(s) 215, and a remote system 220.
  • the server(s) 215 represent various scalable instances of components of the infrastructure 1 10 described with respect to FIG. 1.
  • the model system 200 also includes additional components 225, such as an administrator portal, a physician portal, and subject data endpoints.
  • the client device 205 and medical device 210 may be actively or passively operated upon by a user and in doing so generate and/or collect data (e g., healthcare data) may be generated and/or collected from a SAMD application (e.g., SAMD application 305 in FIG. 3) running on the client device 205 or healthcare data may generated and/or collected from a neuromodulation device implanted in a subject).
  • a software development kit associated with one or more applications on the client device 205 and/or the medical device 210 are adapted to allow for the registration, administration, and expiration of the medical device 210 for a subject.
  • the subject can be a user associated with the client device 205 and the medical device 210.
  • the server(s) 215 can receive an identifier of the medical device 210 that includes software for administering a treatment to the subject.
  • the medical device 210 may be an injection device for injecting a dose of a drug into the subject.
  • the medical device 210 may be a dispensing device that dispenses a dose of a drug to the subject.
  • Other medical devices are also possible.
  • the identifier can uniquely correspond to the medical device 210.
  • the medical device 210 can be qualified and validated prior to being trusted by the server(s) 215 for use by the subject. So, the server(s) 215 can perform a qualification procedure and a validation procedure for the medical device 210.
  • the qualification procedure and the validation procedure can each include one or more tests or operations that verify that the medical device 210 performs according to operational and security specifications.
  • the server(s) 215 can register the medical device 210 as a trusted device for administering treatment. If the medical device 210 does not successfully complete one or both of the qualification procedure or the validation procedure, the server(s) 215 may prevent the medical device 210 from being registered as a trusted device.
  • the server(s) 215 can associate the medical device 210 with the client device 205.
  • the subject may receive the medical device and then access the SAMD application 305 on the client device 205.
  • the subject may execute a registration process to associate the client device 205 with the medical device 210.
  • the subject may input the identifier of the medical device 210 into the application, which can send the identifier to the server(s) 215. and the server(s) 215 can verify that the identifier matches the identifier of the medical device 210 that was provided to the subject.
  • the server(s) 215 can generate unique identifiers 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 treatment by the medical device 210.
  • Each of the unique identifiers may be a blockchain hash. So, the served s) 215 can generate a client authentication blockchain hash that is assigned to the client device 205 and a medical device authentication blockchain hash that is 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(s) 215 can store an association between an identifier of the subject, the client authentication blockchain hash, and the medical device authentication blockchain hash.
  • the association may be stored in a datastore that includes associations of subject identifiers, client devices, and medical devices for multiple subjects.
  • the server(s) 215 can monitor subject data for the subject to determine parameters for treatment administration.
  • the subject data may be collected from one or more computing devices that monitor health attributes of the subject.
  • the server(s) 215 may receive the subject data from one or more of the components 225.
  • the computing devices may include a clinical device sensor and/or a handheld portable device.
  • the computing device may be a wearable, such as a watch, that is worn by the subject and that monitors a heart rate and other health attributes of the subject.
  • the subject data can be input into one or more models that identify parameters associated with administering treatment to the subject using the medical device 210.
  • the parameters can 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 a recommendation of the parameters.
  • the server(s) 215 can then control the administration of treatment for the subject according to the parameters.
  • the server(s) 215 can send a notification to the client device 205 that indicates the time window to the subject.
  • 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 on the client device 205.
  • the login may involve the subject providing unique identification information of the subject, such as a username and password, to access an account that is associated with the medical device 210.
  • the unique identification information may be a biometric identifier (e.g., fingerprint or face identification) of the subject.
  • the server(s) 215 can receive the login along with the client authentication blockchain hash associated with the client device 205.
  • the server(s) 215 may additionally receive an indication of the medical device authentication blockchain hash that is associated with the medical device 210 of the subject.
  • the server(s) 215 can then verify an association of the client authentication blockchain hash and the medical device authentication blockchain hash with the subject. For instance, the server(s) 215 can perform a lookup of the datastore 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(s) 215 can approve an administration of the treatment to the subject. For example, the server(s) 215 can send an indication of the approval to either to the medical device 210 directly or to the client device 205. In response to the approval, the medical device 210 can perform the administration.
  • the medical device 210 may automatically perform the administration based on receiving the approval, or the medical device 210 may receive an additional instruction of the administration after receiving the approval.
  • the server(s) 215 may send an instruction to either the medical device 210 directly or to the client device 205 that then forwards the instruction that causes the medical device 210 to dispense the treatment.
  • the remote system 220 may be the developer of the medical device 210, and the remote system 220 may periodically generate updates to firmware of the medical device 210.
  • the server(s) 215 of the digital health platform can qualify and validated each update to ensure security and successful operation of the updates before the updates are sent to the medical device 210.
  • the server(s) 215 can schedule a sending of the update to the medical device 210.
  • the server(s) 215 may schedule the sending for a time that is outside the time window of when the treatment is to be administered to the subject so that the update does not interfere with the treatment. At the scheduled time, the server(s) 215 can push the update to the medical device 210.
  • the medical device 210 may generate data, such as logs, about treatment administrations and send the data to the server(s) 215.
  • the server(s) 215 can process the data (e.g., clean, anonymize, de-identify, etc.) and then send the processed data to the remote system 220. So, the remote system 220 may receive data that can inform updates or other developments of the firmware without receiving sensitive or other unnecessary information.
  • the server(s) 215 may set a requirement that each medical device is to have a particular firmware version to remain registered as a trusted medical device. For instance, the server(s) 215 may specify 7 that a medical device needs to be updated to a latest firmware version within a particular time period (e.g., one week) of the server(s) 215 receiving the update to the firmware. After the particular time period passes, the server(s) 215 may determine that the medical device 210 does not include the updated firmware. As a result, the server(s) 215 can expire the medical device authentication blockchain hash that is associated with the medical device 210 so that treatments can no longer be administered by the medical device 210. The server(s) 215 may expire blockchain hashes for all registered medical devices that do not include a specified version of the firmware simultaneously.
  • a particular time period e.g., one week
  • medical devices may be expired based on a performance of the treatment.
  • the server(s) 215 can monitor an efficacy or other performance of the treatment by periodically receiving data indicating the efficacy or performance. If the performance is below a threshold, the server(s) 215 can expire the blockchain hashes for any registered medical device that administers the treatment. In this way, subjects may be prevented from receiving a treatment in substantially real time to the determination of reduced performance of the treatment. IV. Techniques for integrating a medical device with a digital health platform
  • FIGS. 4-5 illustrate processes and operations for integrating medical devices into a digital health platform.
  • Individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged.
  • a process is terminated when its operations are completed, but could have additional steps not included in a figure.
  • 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 a return of the function to the calling function or the main function.
  • FIGS. 4-5 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors cores), hardware, or combinations thereof.
  • processing units e.g., processors cores
  • FIGS. 4 and 5 may be performed by a digital health platform 100 and/or a model systems 200/300 to control, expire or register a medical device 210.
  • the software may be stored in a memory (e.g., on a memory device, on a non-transitory computer-readable storage medium).
  • the particular series of processing steps in FIGS. 4-5 is not intended to be limiting.
  • FIG. 4 illustrates a process 400 for controlling a medical device 210 using a digital health platform 100.
  • subject data of a subject associated with a medical device 210 is identified.
  • the subject data may be received from one or more devices, such as sensors, wearables, physician computer systems, or a mobile device of the subject.
  • a digital health platform 100 can receive the subject data.
  • one or more parameters associated with administering a treatment to the subject are determined based on the subject data.
  • the parameters can include a time window for administering the treatment.
  • the subject data may be input into a machine learning model that outputs recommended parameters for the administration of the treatment to the subject.
  • a notification is sent to a client device 205 (e.g., the mobile phone of the subject) indicating the time window.
  • the notification may be sent prior to or during the time window to notify the subject of an upcoming treatment administration.
  • an authentication procedure is received from the client device 205 during the time window.
  • the authentication procedure can include the subject logging in to an application on the client device 205 that is associated with the digital health platform 100.
  • the subject may need to provide unique identification information (e.g., biometric information) during the authentication procedure.
  • the client device can 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.
  • an 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 datastore that includes associations 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 the subject is determined to be associated with the client authentication blockchain hash and the medical device authentication blockchain hash, the association is verified, meaning that the administration of treatment can proceed.
  • FIG. 5 illustrates a process 500 for registering and expiring a medical device 210 with a digital health platform 100.
  • an identifier of a medical device 210 including software for administering a treatment to a subject is received. The identifier can uniquely correspond to the medical device 210.
  • a qualification procedure and a validation procedure are performed for the medical device 210.
  • the qualification procedure and the validation procedure can each include one or more tests or operations that verify that the medical device 210 performs according to operational and security specifications.
  • the qualification procedure and the validation procedure are determined to be successful.
  • the qualification procedure and the validation procedure may be successful if each test, a threshold number of tests, or a particular subset of the tests produce desired results for the medical device 210.
  • 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 qualification procedure or the validation procedure, the medical device 210 may be prevented from being registered as a trusted device, and thus may not be used for providing treatment.
  • a client device 205 of the subject is associated with the medical device 205.
  • the subject may access an SAMD application 305 on the client device 205 to associate the client device 205 with the medical device 210.
  • the subject may execute a registration process using the SAMD application 305 to associate the client device 205 with the medical device 210.
  • the subject may input the identifier of 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 that was provided to the subject.
  • a client authentication blockchain hash is assigned to the client device 205 and a medical device 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 treatment is administered to the 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 may be expired at some point if firmware of the medical device 210 does not satisfy requirements set by the digital health platform 100 or if performance of the treatment is below a threshold. Expiring the medical device authentication blockchain hash can prevent any future administration of treatment by the medical device 210. Accordingly, the digital health platform 100 can facilitate registration, control, and expiration of medical devices to provide approval and administration of treatment without physician presence, while remaining compliant with regulations.
  • any reference to a series of examples is to be understood as a reference to each of those examples disjunctively (e.g., "Examples 1-4" is to be understood as “Examples 1, 2, 3, or 4").
  • Example 1 is a computer-implemented method of controlling a medical device comprising: 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, wherein a parameter of the one or more parameters comprises a time window for administering the treatment; sending a notification indicating the time window to a client device associated with the subject; receiving, from the client device associated with the subject, an authentication procedure during the time window, wherein the authentication procedure includes 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 an administration of the treatment to the subject in response to verifying the association.
  • Example 2 is the computer-implemented method of example 1 , wherein identifying the subject data comprises: receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.
  • 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.
  • Example 4 is the computer-implemented method of any of example(s) 1 -3, further comprising: prior to identifying the subject data: receiving an indication of a registration of the medical device; generating the medical device authentication blockchain hash for the medical device; storing the association between the medical device authentication blockchain hash and an identifier of the subject; and injecting the medical device authentication blockchain hash into the medical device for authenticating the medical device.
  • Example 5 is the computer-implemented method of any of example(s) 1 -4, further comprising: receiving the authentication procedure by receiving a login of the subject to a software application on the client device, wherein the login includes unique identification information of the subject, and wherein the client device is configured to send the client authentication blockchain hash in response to the login to the software application.
  • Example 6 is the computer-implemented method of example 5, wherein the unique identification information is a biometric identifier of the subject.
  • Example 7 is the computer-implemented method of any of exampl e(s) 1-6, wherein verifying the association comprises: accessing a datastore that includes a plurality of associations between a plurality of identifiers for a plurality of subjects and a plurality of blockchain hashes; and determining the datastore includes an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash.
  • Example 8 is the computer-implemented method of any of example(s) 1-7, further comprising: receiving, from a remote computing system, an update to firmware for the medical device; scheduling a sending of the update to the medical device; and pushing the update to the medical device based on the scheduling.
  • Example 9 is the computer-implemented method of example 8, wherein scheduling the sending of the update to the medical device comprises: scheduling the sending for a time outside of the time window.
  • Example 10 is the computer-implemented method of example 8, further comprising: determining that the medical device excludes the update to the firmware subsequent to a predefined period of time passing since receiving the update; and in response to determining that the medical device excludes the update, expiring the medical device authentication blockchain hash associated with the medical device to prevent an additional administration of the treatment by the medical device.
  • Example 11 is a computer-implemented method of registering and expiring a medical device comprising: receiving an identifier of a medical device including software for administering a treatment to a subject; performing a qualification procedure and a validation procedure for the medical device; determining the qualification procedure and the validation procedure are successful for the medical device: registering the medical device as a trusted device for administering the 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 for authenticating the client device and a medical device authentication blockchain hash to the medical device for authenticating the medical device prior to administering the treatment to the subject.
  • Example 12 is the computer-implemented method of example 1 1, further comprising: receiving, from a remote computing system, an update to firmware for the medical device; scheduling a sending of the update to the medical device; and pushing the update to the medical device based on the scheduling.
  • Example 13 is the computer-implemented method of example 12, wherein scheduling the sending of the update to the medical device comprises: scheduling the sending for a time outside of a time window for administering the treatment to the subject.
  • Example 14 is the computer-implemented method of any of example(s) 12-13, further comprising: determining that the medical device excludes the update to the firmware subsequent to a predefined period of time passing since receiving the update; and in response to determining that the medical device excludes the update, expiring the medical device authentication blockchain hash associated with the medical device to prevent an administration of the treatment by the medical device.
  • Example 15 is the computer-implemented method of any of example(s) 12-14, further comprising: receiving data indicating a 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 an administration of the treatment by the medical device.
  • Example 16 is the computer-implemented method of any of example(s) 11-15, further comprising: identifying subject data of the subject associated with the medical device; determining one or more parameters associated with administering the treatment to the subject using the medical device based on the subject data, wherein a parameter of the one or more parameters comprises a time window for administering the treatment; sending a notification indicating the time window to the client device associated with the subject; receiving, from the client device associated with the subject, an authentication procedure during the time window, wherein the authentication procedure includes the client authentication blockchain hash associated with the client device and the 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 an administration of the treatment to the subject in response to verifying the association.
  • Example 17 is the computer-implemented method of example 16, wherein identifying the subject data comprises: receiving the subject data from one or more computing devices configured to monitor one or more health attributes of the subject.
  • 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.
  • Example 19 is the computer-implemented method of any of example(s) 11-18, further comprising: storing an association between the medical device authentication blockchain hash and an identifier of the subject; and injecting the medical device authentication blockchain hash into the medical device for authenticating the medical device.
  • Example 20 is the computer-implemented method of any of example(s) 1 1-19, further comprising: receiving a login of the subject to a software application on the client device, wherein the login includes unique identification information of the subject, and wherein the client device is configured to send the client authentication blockchain hash in response to the login to the software application.
  • Example 21 is the computer-implemented method of example 20, wherein the unique identification information is a biometric identifier of the subject.
  • Example 22 is the computer-implemented method of example(s) 16-21, wherein verifying the association comprises: accessing a datastore that includes a plurality of associations between a plurality of identifiers for a plurality of subjects and a plurality of blockchain hashes; and determining the datastore includes an identifier of the subject associated with the client authentication blockchain hash and the medical device authentication blockchain hash.
  • Example 23 is a system comprising: one or more data processors; and a non- transitory computer readable storage medium containing instructions which, when executed on the one or more data processors, cause the one or more data processors to perform part or all of one or more methods disclosed herein.
  • Example 24 is a computer-program product tangibly embodied in a non-transitory machine-readable storage medium, including instructions configured to cause one or more data processors to perform part or all of one or more methods disclosed herein.
  • Some embodiments of the present disclosure include a system including one or more data processors.
  • the system includes a non-transitory 7 computer readable storage medium containing instructions which, when executed on the one or more data processors, cause the one or more data processors to perform part or all of one or more methods and/or part or all of one or more processes disclosed herein.
  • Some embodiments of the present disclosure include a computer-program product tangibly embodied in anon- transitory machine-readable storage medium, including instructions configured to cause one or more data processors to perform part or all of one or more methods and/or part or all of one or more processes disclosed herein.
  • circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail.
  • well-known circuits, processes, algorithms, structures, and techniques may be show n without unnecessary detail in order to avoid obscuring the embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Medical Informatics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Medicinal Chemistry (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioethics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

La présente divulgation concerne des techniques permettant d'intégrer un dispositif médical dans une plateforme de santé numérique. En particulier, des aspects concernent l'identification de données de sujet d'un sujet associé à un dispositif médical ; la détermination d'un ou de plusieurs paramètres associés à l'administration d'un traitement au sujet à l'aide du dispositif médical sur la base des données de sujet ; l'envoi d'une notification à un dispositif client associé au sujet ; la réception, en provenance du dispositif client associé au sujet, d'une procédure d'authentification, la procédure d'authentification comprenant un hachage de chaîne de blocs d'authentification de client associé au dispositif client et un hachage de chaîne de blocs d'authentification de dispositif médical associé au dispositif médical ; la vérification d'une association du hachage de chaîne de blocs d'authentification de client et du hachage de chaîne de blocs d'authentification de dispositif médical avec le sujet ; et l'approbation d'une administration du traitement au sujet en réponse à la vérification de l'association.
PCT/US2023/080905 2022-11-29 2023-11-22 Gestion de l'intégration d'un dispositif médical dans une plateforme informatique Ceased WO2024118431A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020257018887A KR20250116035A (ko) 2022-11-29 2023-11-22 의료 장치의 컴퓨팅 플랫폼 통합 관리
CN202380081586.6A CN120303744A (zh) 2022-11-29 2023-11-22 对医疗装置到计算平台中的集成进行管理
EP23828632.2A EP4627592A1 (fr) 2022-11-29 2023-11-22 Gestion de l'intégration d'un dispositif médical dans une plateforme informatique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263385321P 2022-11-29 2022-11-29
US63/385,321 2022-11-29

Publications (1)

Publication Number Publication Date
WO2024118431A1 true WO2024118431A1 (fr) 2024-06-06

Family

ID=89321851

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/080905 Ceased WO2024118431A1 (fr) 2022-11-29 2023-11-22 Gestion de l'intégration d'un dispositif médical dans une plateforme informatique

Country Status (4)

Country Link
EP (1) EP4627592A1 (fr)
KR (1) KR20250116035A (fr)
CN (1) CN120303744A (fr)
WO (1) WO2024118431A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030140928A1 (en) * 2002-01-29 2003-07-31 Tuan Bui Medical treatment verification system and method
US20170209718A1 (en) * 2010-10-12 2017-07-27 Smith & Nephew, Inc. Medical device
WO2020142270A1 (fr) * 2018-12-31 2020-07-09 Becton, Dickinson And Company Systèmes, appareils et procédés de communication de dispositif médical avec un ou plusieurs dispositifs distants

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030140928A1 (en) * 2002-01-29 2003-07-31 Tuan Bui Medical treatment verification system and method
US20170209718A1 (en) * 2010-10-12 2017-07-27 Smith & Nephew, Inc. Medical device
WO2020142270A1 (fr) * 2018-12-31 2020-07-09 Becton, Dickinson And Company Systèmes, appareils et procédés de communication de dispositif médical avec un ou plusieurs dispositifs distants

Also Published As

Publication number Publication date
CN120303744A (zh) 2025-07-11
KR20250116035A (ko) 2025-07-31
EP4627592A1 (fr) 2025-10-08

Similar Documents

Publication Publication Date Title
US11740943B2 (en) Techniques for managing long-running tasks with a declarative provisioner
US12153934B2 (en) Techniques for managing dependencies of an orchestration service
US20250039157A1 (en) Techniques for transferring data across air gaps
WO2019138128A1 (fr) Procédé et système de fourniture d'accès sécurisé à des artefacts dans un environnement informatique en nuage
US20230359455A1 (en) Service orchestration within a distributed pod based system
EP4094155A1 (fr) Techniques d'utilisation de graphes acycliques orientés pour des instructions de déploiement
US20240129306A1 (en) Service to service communication and authentication via a central network mesh
Santos et al. A federated learning platform as a service for advancing stroke management in european clinical centers
WO2024118431A1 (fr) Gestion de l'intégration d'un dispositif médical dans une plateforme informatique
JP2025540747A (ja) コンピューティングプラットフォームへの医療デバイスの統合の管理
Lomotey et al. Composition of the electronic health record: Mobile efficiency in mHealth
CN103124287A (zh) 通过独特的移动应用程序地址进行第三方内容传输的技术

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23828632

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202380081586.6

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2025531013

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2025531013

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2023828632

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2023828632

Country of ref document: EP

Effective date: 20250630

WWP Wipo information: published in national office

Ref document number: 202380081586.6

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 1020257018887

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2023828632

Country of ref document: EP