EP2989576B1 - Sicherheitssystem mit kontomanager für eine tragbare medizinische vorrichtung - Google Patents

Sicherheitssystem mit kontomanager für eine tragbare medizinische vorrichtung Download PDF

Info

Publication number
EP2989576B1
EP2989576B1 EP14727716.4A EP14727716A EP2989576B1 EP 2989576 B1 EP2989576 B1 EP 2989576B1 EP 14727716 A EP14727716 A EP 14727716A EP 2989576 B1 EP2989576 B1 EP 2989576B1
Authority
EP
European Patent Office
Prior art keywords
account
patient
data
accounts
manager
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.)
Active
Application number
EP14727716.4A
Other languages
English (en)
French (fr)
Other versions
EP2989576A2 (de
Inventor
Erik CARLSGAARD
Aaron Dinwiddie
Igor Gejdos
Michael Lee Long
Teresa OELMANN
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
Roche Diabetes Care GmbH
Original Assignee
F Hoffmann La Roche AG
Roche Diabetes Care GmbH
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, Roche Diabetes Care GmbH filed Critical F Hoffmann La Roche AG
Priority to EP18187339.9A priority Critical patent/EP3462457B1/de
Publication of EP2989576A2 publication Critical patent/EP2989576A2/de
Application granted granted Critical
Publication of EP2989576B1 publication Critical patent/EP2989576B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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
    • 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
    • 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/63—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 local operation
    • 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/20—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 or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • 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

Definitions

  • the present disclosure relates to portal control features that pertain to a diabetes management system.
  • blood glucose meters allow them to periodically measure their glucose levels and take appropriate action, such as administering insulin.
  • a diabetic patient may find it useful to communicate these measurements to his or her healthcare professional for further review and analysis.
  • the patient's blood glucose meter may be capable of storing the blood glucose measurements for later review and analysis by the patient or the healthcare professional, who may then record the measurements manually or electronically.
  • the process of measuring, storing, recording and analyzing blood glucose levels can be a very time consuming process for both the patient and the patient's healthcare professional. Often, the exchange and review of data requires a meeting between the patient and the healthcare professional. People with diabetes are often searching for better and more efficient ways to manage their health. In addition, healthcare professionals need new tools to motivate people with diabetes to communicate more effectively. Technology can provide a viable platform for software applications for a wide variety of consumer demands. Moreover, many people with diabetes use personal computers and/or mobile devices in their daily lives.
  • Patent application US 2010/223184 A1 describes systems and methods for primary and sponsored accounts.
  • the system comprises an account processor to execute software instructions for creating and managing electronic payment accounts and an accounts database to store accounts data from the account processor.
  • the account processor may be configured to create a primary account and a sponsored account in the accounts database.
  • the primary account may be associated with a primary account holder who has access to the primary account to add and remove funds.
  • the sponsored accounts may be associated with both the primary account holder and a sponsored account holder, where the primary account holder has access to the sponsored account to transfer funds between the primary account and the sponsored account in order to add and remove funds from the sponsored account, and the sponsored account holder has access to the sponsored account for making transactions using funds in the sponsored account.
  • US patent application US 2007/100222 A1 describes a system for monitoring blood glucose data of a patient.
  • the system includes a sensing device and hospital monitor.
  • the sensing device includes a sensor and sensor electronics and is adapted to transmit information to the hospital monitor while continuing to sense blood glucose data.
  • the communication between the sensing device and the hospital monitor may be wireless.
  • the sensor electronics may include a sends a power supply, a voltage regulator, and optionally a memory and processor.
  • US patent application US 2008/071580 A1 describes a diabetes management system (DDMS) and corresponding method for assisting a healthcare professional and monitoring and evaluating the progress of a diabetic patient by generating various types of reports that are indicative of periodic trends in the patient's behavior, including compliance with a prescribed course of therapy.
  • input data including carbohydrate, insulin, and glucose data are uploaded by the patient into the DDMS, which then generates periodic, e.g. weekly, patient-specific output data in the form of box plot graphs, bar graphs, etc. over an extended period of time.
  • US patent application US 2001/0032099 describes an apparatus and method for processing and providing healthcare information, and for remotely monitoring patients' conditions.
  • a problem involved with measuring blood glucose levels with portable glucose meters is that the management of health data is time consuming both for the patient and for the healthcare provider and that sensitive patient data may be visible to third parties if the glucose meter or a personal computer comprising sensitive patient data is lost or stolen.
  • the invention relates to a security system for medical data.
  • the system comprises a portable medical device for measuring medical parameters which are indicative of a physiological state of a mammal, e.g., a patient.
  • the system further comprises a server device which comprises and/or which is operatively coupled to a storage device.
  • the server device hosts an accounts manager of a diabetes management system.
  • the accounts manager is configured to manage accounts stored on said storage device.
  • Said accounts comprise a first account associated with a healthcare provider and a plurality of patient accounts associated with said first account.
  • Each patient account comprises medical data of a respective patient.
  • the system further comprises a mobile device hosting an application program.
  • Said application program is interoperable with the portable medical device and with the accounts manager.
  • the mobile device is connected with the server device via a network.
  • the mobile device may be, for example, a mobile phone, in particular a smart phone, a tabloid computer, a notebook or the like.
  • the portable medical device is configured to repeatedly measure medical parameters of one of said patients.
  • the application program is configured to repeatedly and fully automatically receive the measured medical parameters from said measurement device.
  • the application program may be configured to immediately forward the received measured medical parameters to the accounts manager for storing said parameters on the storage device of the server as part of the patient account of said patient.
  • the portable medical device, the application program and the accounts manager are configured such that only a single copy of the measured medical data is permanently stored in said storage device and such that any temporally created copies of said measured medical data are immediately erased from the portable medical device and the mobile device after execution of the forwarding.
  • the account manager is configured to execute the following steps:
  • Said features may be advantageous for multiple reasons: that the measurement data is automatically forwarded and centrally stored by the server device may ease the collection and storing of health-related measurement data for the patient.
  • a continuous collection of such data may be advantageous as said data may be used for diagnostic purposes and in order to determine an appropriate treatment schema and an appropriate amount of drug for treatment.
  • the forwarding is executed fully automatically, the patient is freed of the burden of submitting said data manually and the chances rise that the forwarded measurement data provides a complete documentation of the measured parameter over a longer period of time.
  • only a single copy of the measured medical data is permanently stored in said storage device of the server.
  • the portable medical device nor the mobile device of the patient store a copy of the measurement data as said data is immediately erased after a successful forwarding.
  • Any temporally created copies of said measured medical data e.g. data kept in the main memory of the portable medical device or the mobile device, are immediately erased after the forwarding of the data to the server device. This ensures that even in case the portable medical device and/or the mobile device should be lost, an unauthorized person having found or having stolen said devices will not be able to obtain any measurement data from the device as the only existing copy is stored on a storage device of the server.
  • the data is also protected in case a healthcare provider having assigned the first account has lost his access credentials, e.g. because his or her notebook having stored the access credentials to the first account have been stolen. In such an event, the healthcare provider merely needs to send a request for deactivating his account to the accounts manager. This request will also result in a deactivation of all patient accounts of patients said healthcare provider is responsible for.
  • an automated, centralized and secure way of collecting and managing medical measurement data and accounts is provided.
  • embodiments of the invention may improve the effectiveness and efficiency of storing, communicating and analyzing blood glucose measurements. Redundantly storing multiple copies of the data on different devices of the patient and the patient's healthcare professional may be avoided. Sending data, including blood glucose measurements, to a centralized electronic data repository for later retrieval and analysis may reduce the amount of consumed storage space and network traffic.
  • the centrally stored patient data is available for the patient and the patient's healthcare professional at various times and from various locations.
  • the sharing of data and the data repository can be managed by a single set of collectively manageable administrative guidelines implemented e.g. by rules executed by the server device. Such administrative guidelines may need to follow certain procedures for opening, closing, and deactivating both patient and healthcare provider accounts associated with the data sharing and storage.
  • the portable medical device comprises a processor and an interface for exchanging data with the application program.
  • the interface is capable of pairing the portable medical device to the application program.
  • the portable medical device and the application program are connected via a data communication connection. Only in the paired state the one portable medical device is configured for enabling a transferring of measurement data to the application program.
  • the application program may execute the pairing in interoperation with the portable medical device if the application program determines by evaluating a device-ID of the portable medical device that said device has already successfully registered at the accounts manager.
  • Said features may be advantageous as they may ensure that the application program only forwards measurement data gathered by a portable medical device that has successfully paired with the application program and that thus can reliably be considered as trustworthy.
  • a portable medical device that has successfully paired with the application program and that thus can reliably be considered as trustworthy.
  • the accounts manager may refuse to register such kinds of medical devices. Said refusal may be communicated from the accounts manager to the application program. This will automatically result in an incapability of the portable medical device and the application program to establish a pairing and to forward the medical data via the application program to the accounts manager. This may help to protect the safety of the patient and to increase the quality of the measurement data stored and managed by the accounts manager.
  • the connection established after pairing may be a WiFi connection, a Bluetooth connection, a cable connection, or any other suitable data transfer connection.
  • the connection is secured by a cryptographic protocol, e.g. SSH and/or TLS. If the pairing was executed successfully, the portable medical device and the application program are in a paired state. Otherwise, both objects are not in the paired state.
  • the application program is configured to execute steps comprising:
  • the storage medium of the mobile device may already have stored the device-ID in association with the patient's patient-ID and in association with a confirmation of the accounts manager that said portable medical device has successfully registered at the accounts manager.
  • Said confirmation of the accounts manager may comprise a signature that can be verified by the application program by means of a certificate chain evaluation.
  • Said features may be advantageous as they ensure that only trusted portable medical devices with known quality standards may be used to upload medical measurement data to the accounts manager.
  • the uploading is facilitated.
  • Said features may be advantageous as it is possible to make use of portable medical devices of a type that is not able to communicate a unique device-ID to the application program.
  • By automatically generating a device-ID and storing said generated ID in a storage medium of the device it is possible to provide the above described security system also based on device types originally lacking a suitable device-ID.
  • the accounts manager is configured such that only measurement data collected by a portable medical device having successfully been registered at the accounts manager is received and stored in association with a respective patient account.
  • the application program may be configured such that only measurement data collected by a portable medical device having successfully been registered at the accounts manager is forwarded to the accounts manager.
  • the device-ID of the portable medical device is a MAC address of the device, a serial number of the device, or any other data value that is unique for said portable medical device and that can be read out by the application program or that can otherwise be communicated from the portable medical device by the application program.
  • the portable medical device may not comprise such a device-ID.
  • the application program may generate a random data value upon initial registration of said device at the account manager and store said device-ID in a storage of said portable medical device and in a data store of the mobile device hosting the application program. In said cases, the generated random number may be used as the device-ID; the determination may involve the application program interacting with the portable medical device to execute the following steps:
  • the user does not have to authenticate at the account manager by means of a password or fingerprint once his portable medical device was registered at the accounts manager. Rather, a device-ID of the portable medical device is sent together with the measurement data to the accounts manager. Said device-ID is used to assign the forwarded measurement data to the patient account of the patient owning or using said portable medical device.
  • the forwarding of the measurement data is accelerated, facilitated and automated. Nevertheless, the method is save as the device registration process requires a user authentication at the account manager.
  • the medical measuring device is a glucose meter.
  • the measurement data may be a glucose level obtained by analyzing, for example, a blood sample, a urine sample or a saliva sample of the patient.
  • the account manager is configured to execute, upon receiving the request to deactivate the first account, the steps of:
  • This may be advantageous as it is prohibited that a patient may forward sensitive patient data contained in his patient account to the first account of his health care provider in case it cannot be ensured that an unauthorized third party may have acquired access credentials of said health care provider.
  • the invention relates to a computer-implemented method for managing accounts in a diabetes management system, the method being implemented in a security system as described above, the method comprising:
  • the predetermined period of time can be associated with a regulatory compliance.
  • the regulatory compliance is associated with a geographic location of the patient, e.g., a country that may be represented in a patient's account by a country code.
  • the method further comprises disabling, by the account manager, data synchronization functions.
  • Data synchronization functions are functions which are configured to exchange data between a first and a second storage device. The exchanged data may belong to the first account and/or to one of the identified patient accounts.
  • the first storage device is part of and/or is operatively coupled to the server device.
  • the second storage device being part of a portable medical device.
  • the portable medical device may be, for example, a glucose meter, an insulin pump, or the like.
  • the data synchronization is performed with the help of an application program installed on a patient's mobile device.
  • the application program manages data exchange during synchronization without storing the exchanged data to a storage of the mobile device: only a single copy of the data is stored on the storage of the server device.
  • the method further comprises disabling, by the account manager, data sharing functions.
  • Data sharing functions are functions which are configured to exchange data between the first account and each of the identified patient accounts.
  • the data belonging to the first account and data belonging to the identified patient accounts are stored on a storage device that is part of and/or is operatively coupled to the server device.
  • the method further comprises authenticating, by the account manager, the request to deactivate the first account associated with the healthcare provider, and only deactivating the first account in case the request was successfully authenticated.
  • Authenticating the request may imply checking if the request was submitted by the healthcare provider assigned to the first account to be deactivated.
  • the first account is only deactivated if said request was submitted by said healthcare provider.
  • the first account is not deactivated if the request was submitted by another, i.e., unauthenticated person.
  • the account manager sends a confirmation that the first account and the associated patient accounts are deactivated in response.
  • the confirmation is sent to the instance having submitted the request for deactivating the first account.
  • the account manager creats an event log record in a data store.
  • the event log record indicates the deactivation date of each of the identified patient accounts.
  • Said data store may be part of and/or may be operatively coupled to the server device.
  • At least a portion of the data is encrypted.
  • the request to deactivate the patient account originates from the healthcare provider whose first account is associated with said patient account.
  • the electronic notification is provided to a patient associated with the patient account.
  • the notification may be executed by e-mail, SMS and/or a graphical user interface provided by the account manager and communicated over a network.
  • Said GUI may be displayed by a browser installed on the mobile device of the patient and/or may be displayed by the application program installed on said mobile device.
  • the method further comprises authenticating, by the account manager, the request to deactivate the patient account prior to deactivating the patient account.
  • the patient account is only deactivated in case the request was successfully authenticated.
  • a request may be successfully authenticated if the account manager receives some data being able to proof that said request was received from said very patient or from a healthcare-provider whose first account is associated to said patient account.
  • Said data may be provided in the form of authentication data, e.g. a password and/or biometrical data.
  • the patient account is associated with a portable medical device. This may be accomplished, for example, by storing a patient-ID or a patient account-ID in association with a device-ID of said portable medical device, patient data belonging to said patient account is stored on a storage medium that belongs to and/or is operatively coupled to the server device.
  • the method may further comprise disabling, by the account manager, data transfer between the portable medical device and said patient account upon a deactivation of said patient account.
  • the method further comprises disabling, by the account manager, data transfer between an electronic medical records system and said patient account upon a deactivation of said patient account.
  • patient data belonging to said patient account is stored on a storage medium that belongs to and/or is operatively coupled to the server device.
  • the method may further comprise providing, by the account manager, an option to cancel the request to deactivate the patient account.
  • the invention relates to a method for managing accounts in a diabetes management system, comprising:
  • the present disclosure provides a method for managing accounts in a diabetes management system.
  • the system can include receiving, by an account manager, a request to deactivate a first account associated with a healthcare provider.
  • the first account may be associated with a plurality of patient accounts.
  • the account manager may be implemented as computer executable instructions executing on a computer processor of a server device.
  • the method can include removing, by the account manager, access to data associated with the first account.
  • Each of the patient accounts associated with the first account are identified by the account manager and deactivated.
  • An electronic notification may be sent by the account manager to a person associated with each of the identified patient accounts. The electronic notification may advise the person that the corresponding patient account has been deactivated.
  • the method may include creating, by the account manager, an audit record in a data store, where the audit record indicates the deactivation of the first account.
  • the method for managing accounts in a diabetes management system comprises receiving, by an account manager, a request to deactivate a patient account associated with the diabetes care management system.
  • the account manager may be implemented as computer executable instructions executing on a computer processor of a server device.
  • the account manager may provide a warning notification indicating active sessions of the patient account will be terminated.
  • the method can include soliciting, by the account manager, a confirmation of the request to deactivate the patient account.
  • the patient account may be deactivated upon receipt of the confirmation of the request to deactivate the patient account.
  • the account manager may send an electronic notification to a person associated with the patient account, where the electronic notification advises the person that the corresponding patient account has been deactivated.
  • the method can include creating, by the account manager, an audit record in a data store, where the audit record indicates the deactivation of the patient account.
  • the above described method may be computer-implemented.
  • FIG 1 illustrates an exemplary diabetes management system (“DMS") 10 for storing and transmitting medical data and information across a distributed computing environment.
  • data and information might include blood glucose measurements, search engine functionality, alerts and reminders, user-entered notes, reports and graphs, and global positioning system information.
  • the diabetes management system 10 may include generally a patient data system 12, a healthcare professional data system 14, a network 16, and at least one server computer 18.
  • the terms 'server computer', 'server' and 'server device' are used herein synonymously.
  • the diabetes management system 10 may be configured such that data and information is electronically sent and received to and from the patient data system 12, the healthcare professional data system 14, and the server computer 18 via the network 16.
  • the diabetes management system 10' illustrated in Figure 3 may also generally include a medical data recording device 28, such as a blood glucose meter, for measuring and storing certain medical data or information, such as blood glucose measurements.
  • the 'data recording device ' is also referred herein as 'medical device'.
  • the medical device is a portable medical device.
  • the medical data recording device 28 may be operable to send medical data or information to at least one of the patient computing device 20 and the healthcare professional computing device 24 through a data transmission device, such as a hard-wired data port or a wireless data port such as a Bluetooth receiver, incorporated therein.
  • the medical data recording device 28 may be associated with a unique identifier or security code that attaches to any data transmitted by the medical data recording device. Accordingly, in this method of data transmission, the patient or other user may not be required to enter a username, password, or other security code prior to transmitting data via the network 16.
  • the patient data system 12 may include at least one patient computing device 20 operably connected to, and in communication with, the network 16 through a wired or wireless connection such as WiFi.
  • the computing device 20 is also referred herein as mobile device.
  • the patient computing device 20 may be a mobile device such as an electronic tablet or a smartphone.
  • the patient computing device 20 may include a data input device, a processor, a memory, and an output device.
  • the data input device may be a touchscreen, a keyboard, a mouse, a microphone, a hard-wired data port such as a universal serial bus port, or a wireless data port such as a Bluetooth receiver.
  • the processor may be connected to the data input device, the memory, and the output device.
  • the processor includes a general purpose processor.
  • the processor includes an application specific integrated circuit.
  • the output device includes a display, a speaker, or the like.
  • a user may enter data or information such as blood glucose measurements into a web browser on the patient computing device 20 via the data input device for transmittal via the network 16.
  • data or information such as blood glucose measurements
  • the user may be required to enter a username, password, or other security code, in order to ensure the accurate transmission and storage of data, as will be described in more detail below.
  • the healthcare professional data system 14 may include at least one healthcare professional computing device 24 operably connected to, and in communication with, the network 16 through a wired or wireless connection, such as WiFi.
  • a physician or other person with access to the healthcare professional computing device 24 may utilize the network 16 to download and view data or information such as blood glucose measurements that are stored on the server computer 18.
  • the healthcare professional computing device 24 may be a desktop computer or a mobile communication device such as an electronic tablet or a smartphone.
  • the healthcare professional computing device 24 may include a data input device, a processor, a memory, and an output device.
  • the data input device may be a touchscreen, a keyboard, a mouse, a microphone, a hard-wired data port such as a universal serial bus port, or a wireless data port such as a Bluetooth receiver.
  • the processor may be connected to the data input device, the memory, and the output device.
  • the processor includes a general purpose processor.
  • the processor includes an application specific integrated circuit.
  • the output device includes a display, a speaker, or the like.
  • the server computer 18 may include a processor, an input device, an output device, and a memory including a database 26.
  • the processor is connected to the memory, the input device, and the output device.
  • the processor includes a general purpose processor.
  • the processor includes an application specific integrated circuit.
  • the input device includes a keyboard, a mouse, a touchpad, a trackpad, or the like.
  • the output device includes a display, a speaker, or the like.
  • the server computer 18 and database 26 may be operably connected to, and in communication with, the network 16 through a wired or wireless connection.
  • the server computer 18 may be operable to send and receive via the network 16 data, such as blood glucose measurements received from the patient data system 12, to the database 26 for storage and later retrieval.
  • data and information sent via the network 16 may be assigned to a unique patient account prior to being stored in the database 26 located on the server computer 18.
  • Figure 3 illustrates an alternative embodiment of the diabetes management system 10'.
  • the alternative embodiment of the diabetes management system 10' shown in Figure 3 may be similar to the embodiment shown in Figure 1 , and include a patient data system 12, a healthcare professional data system 14, a network 16, and at least one server computer 18.
  • the patient data system 12 may include at least one patient computing device 20 operably connected to, and in communication with, the network 16 through a wired or wireless connection such as WiFi.
  • the healthcare professional data system 14 may include at least one healthcare professional computing device 24 operably connected to, and in communication with, the network 16 through a wired or wireless connection, such as WiFi, through which a physician or other person with access to the healthcare professional computing device may download and view data or information such as blood glucose measurements sent from the patient computing device 20 via the network 16.
  • the medical data recording device 28 may be configured to transmit data to at least one of the patient computing device 20, the healthcare professional computing device 24, and the server computer 18 at regular, programmable intervals, at varying times chosen by the user, in real time as blood glucose measurements are taken, or when blood glucose measurements reach certain threshold levels that may be set by the patient or the healthcare professional.
  • the software architecture system 30 may be operable to allow transmission and manipulation of data and information, such as blood glucose measurements, from the medical data recording device 28, through the network 16 and between the patient data system 12, the server computer 18, and the healthcare professional data system 14.
  • data and information such as blood glucose measurements
  • the software architecture system 30 may include a 'device transfer component' 32 that is also referred herein as 'application program' hosted by and running on the mobile device 20.
  • the device transfer component 32 is a piece of program logic stored on the server computer 18 for transmission through the network 16 and installation on the patient computing device 20 and the healthcare professional computing device 24.
  • the device transfer component may be provided for download e.g. in the form of an 'app'. Installation of the device transfer component 32 onto the patient computing device 20 or the healthcare professional computing device 24 will allow such device to send data and information, such as blood glucose measurements, to the health management application 33 installed on the server computer 18.
  • the device transfer component 32 is operable to pass the data to the server computer 18 via the network 16, without storing the data in the device transfer component 32 or the patient computing device 20.
  • a medical device application 34 may be installed on the medical data recording device 28, also referred herein as 'portable medical device', to facilitate the exchange of data and information with the device transfer component 32, as described above.
  • Data sent via the device transfer component 32 may include an identifier code, a device-ID, that is unique to the particular medical data recording device 28 from which it was received.
  • the medical data recording device may uniquely be assigned to a patient and in this case the device-ID may act as a patient-ID, e.g.
  • the device-ID acting as patient-ID may allow the device transfer component 32 and the database 26 to efficiently send, store, and retrieve data from unique locations, or patient accounts, within the database 26.
  • a user Prior to transferring data and information through the network 16, a user may be required to link or associate the medical data recording device 28 with a unique patient account created on the server 18. Authentication may be accomplished by first allowing the medical data recording device 28 to communicate with a patient computing device 20 via an input device such as a USB port or a Bluetooth receiver.
  • the medical data recording device 28 may be assigned a unique identification code or authentication token.
  • Said token may be an XML file, e.g. a SAML token, or the like.
  • the medical data recording device's authentication token can be assigned to the appropriate patient account. Once the medical data recording device's 28 authentication token has been assigned to the patient account, data and information can be transferred through the device transfer component 32 and assigned to the appropriate patient account in the database 26.
  • the device transfer component 32 may be assigned a unique identification code. Prior to transferring data and information from a medical data recording device 28 through the network 16, the user may be required to associate the device transfer component's 32 unique identification code with the patient's account. Data and information from the medical data recording device 28 can be linked to the device transfer component's 32 unique identification code prior to transmission through the network, and thus assigned to the appropriate patient account in the database 26.
  • the software architecture system 30 may allow such data to be further transferred from the patient account to authorized health professional computing devices 24 and patient computing devices 20 via the device transfer component 32. Transfer of data from the patient account located in the database 26 on the server 18 may require linking the patient account with the device transfer component 32 installed on the health professional computing device 24.
  • the software architecture system 30 may also allow a patient, healthcare professional, or other user to create customized reports related to the data and information contained therein or perform research with respect to information contained within or outside of the software architecture system.
  • the software architecture system 30 may be operable to provide data backup and restoration services with respect to data and information that may have been lost from the patient data system 12 or the healthcare professional data system 14.
  • the user may send and receive data from the server computer 18 and the database 26 via a web browser on the patient computing device 20, in lieu of downloading and utilizing the device transfer component 32 on the patient computing device.
  • the server computer 18 may include the device transfer component 32, allowing the user to send data and information to the server computer 18 for storage in the database 26, and for further transmission to the healthcare professional computing device 24 via the network 16.
  • the user may access the diabetes management system 10 and the software architecture system 30' by entering a URL designated for the diabetes management system directly into a web browser.
  • the user Prior to transferring data through the network 16 to the server computer 18, the user may be required to create a unique patient account and security credentials, such as a username and password, to ensure a unique and secured storage location in the database 26. The user may also be required to associate, or link, the medical data recording device 28 authentication token with the patient account. Once the user has created the patient account and linked the medical data recording device 28 authentication code to the patient account, the user may be permitted to transfer data and information to and from the server computer 18 without otherwise logging into the patient account.
  • access to the server 18 via the web browser may allow a user to transmit data such as blood glucose measurements, patient weight, meal information, and similar information, to the patient account in the database 26.
  • access to the server 18 via the web browser may allow the user to create and view reports, graphs, and other information based at least in part on data transmitted from the user.
  • Communication between the patient data system 12, the healthcare professional data system 14, and the server computer 18 may utilize HTTP basic authentication in combination with secure sockets layer (SSL) security protocol.
  • SSL secure sockets layer
  • Other communication and security protocols known in the art are also contemplated.
  • Operation of the diabetes management system 10 may include a user operating a web browser to access the server computer 18 via the network 16.
  • a user may create a unique patient account on the server computer 18 utilizing security credentials such as a username and password. Creation of a patient account may allow the user to send and store data and information in a secure location within the database 26 on the server computer 18.
  • a user may operate a web browser to access the server computer 18 in order to download the device transfer component 32 onto at least one patient computing device 20 and/or at least one health professional computing device 24.
  • a user may register the medical data recording device 28 with at least one of the device transfer component 32 and the patient account. Registration of the medical data recording device 28 with the device transfer component 32 and the patient account may be accomplished by allowing the medical data recording device 28 to communicate with a patient computing device 20 via an input device such as a USB port, a Bluetooth receiver, or other wired or wireless technology.
  • Each medical data recording device 28 may be assigned a unique identification code or authentication token that can be associated with the patient account, thus ensuring that data and information sent from the medical data recording device 28 is stored only in the patient account. It is also contemplated that registration of the medical data recording device 28 with the device transfer component 32 and the patient account may be accomplished by the user directly entering the medical data recording device's identification code or authentication token directly into device transfer component 32 or a web browser.
  • a user may send data and information from the medical data recording device 28 to the device transfer component 32.
  • Data and information may be sent via an input device such as a USB port or a Bluetooth receiver on the patient computing device 20 or the health professional computing device 24.
  • Data and information received from the medical data recording device 28 may include the identification code or authentication token assigned to the particular medical data recording device. In this way, the diabetes management system 10 can ensure the integrity of data and information sent to the patient account.
  • the device transfer component 32 may send data and information received from the medical data recording device 28 to the server 18.
  • the device transfer component 32 may not necessarily store or otherwise record in memory the data and information received from the medical data recording device 28. Rather, the device transfer component 32 may function as an intermediary between the medical data recording device 28 and the server 18, facilitating the transfer of data and information therebetween. Data and information transferred from device transfer component 32 may be authenticated and directed to the patient account through the associated identification code or authentication token received from the medical data recording device 28, as explained above.
  • Data and information associated with the patient account in the server computer 18 database 26 may be transferred to at least one of the patient computing device 20 and the health professional computing device 24 via the network 16.
  • the transfer of data from the server computer 18 may first require authentication.
  • the present technology provides a web-portal by which the owners of the diabetes management system perform various functions related to healthcare provider accounts, patient accounts, or both.
  • a web browser or web-based application may be used to perform similar functions.
  • a healthcare provider may be set up with a first, or main account to help manage treatment of a plurality of different patients, each of which has a respective patient account accessible from the server computer 18 associated with the diabetes management system.
  • the healthcare provider may be able to configure its account to display certain data, statistics, and/or usage data from the various patients having patient accounts accessible through the healthcare provider's account. A review of the data may allow the healthcare provider to better assess the patients' health, and adjust treatment regimens based on the recent and historical data.
  • healthcare providers and patients may readily store, share, and later access medical information relating to the patients, for example, to analyze historical information regarding a subject's biological condition, operation of the patient's portable medical device 28, treatment, treatment results, personal habits, or the like. Based on such historical data, the healthcare provider and/or patient may be able to recognize trends, beneficial practices, detrimental practices or the like and, thereby, adjust or design treatment plans that take advantage of beneficial trends and practices and avoids detrimental trends and practices.
  • the diabetes management system 10 may include software for generating or otherwise providing reports containing information received from a patient, a group of patients, or multiple groups of patients within the same healthcare provider account.
  • a patient or a patient's healthcare provider may readily access formatted reports of information regarding the patient's condition, historical condition, the patient portable medical device operation or condition, or the like, or similar information regarding one or more defined groups of patients.
  • Reports may be formatted in various pre-defined formats provided by the diabetes management system 10.
  • the system 10 may allow patients and/or healthcare providers to design their own report format, including determining what type of information to include in the report and how the information is filtered, presented, displayed, etc.
  • Various aspects of the present disclosure are directed a comprehensive system capable of collecting and managing patient information for multiple patients, the multiple patients with a plurality of different types of medical devices.
  • the sharing of accounts and data, as well as the maintaining of a suitable data repository can be managed by various administrative guidelines. Such administrative guidelines may need to follow certain procedures for opening, closing, and deactivating both patient and healthcare provider accounts associated with the data sharing and storage.
  • Figures 5 and 6 the web-portal or web-based browserlapplications by which either the owners of the diabetes management system or the healthcare providers themselves perform various functions related to healthcare provider accounts, patient accounts, or both can be provided with certain predetermined procedures to activate and deactivate accounts, as well as link healthcare provider accounts with a plurality of patient accounts.
  • Figures 5 and 6 are merely exemplary in nature, and are not mutually exclusive aspects.
  • certain features shown with the method represented in Figure 5 may also be performed with the method represented in Figure 6 , and vice versa, even though they are not specifically shown.
  • not each feature is necessarily a required step of the respective method, and the order in which the method steps are performed should not be limited to the order specifically depicted in the figures or discussed herein.
  • Figure 5 generally represents one non-limiting process associated with the closure or deactivation of a healthcare provider account.
  • an account manager can receive a request to deactivate a first account associated with a healthcare provider, or a healthcare provider account, which in turn may be associated with a plurality of patient accounts that may be linked to the healthcare provider account.
  • the term "account manager” refers to the implementation of computer executable instructions executed on a computer processor of a server device, or the like.
  • an account manager may include a web-based portal or a web-based application, and may include various functionality to perform logic-based operations.
  • the request may be authenticated, as represented by method box 110.
  • Authentication may be accomplished using various techniques, including, but not limited to authentication of username and/or password credentials, permissions, unique identifiers, security questions, or other identifications. Authentication can also include various requests to one or more users seeking a confirmation or acknowledgement of the proposed request.
  • the healthcare provider account may generally be associated with a plurality of patient accounts that are linked by the healthcare provider or diabetes management system operator.
  • patient accounts may be provided with a unique identifier, such as a number, code, or token.
  • the healthcare provider account would be linked together with various patient accounts by association of the healthcare provider account with the unique identifier for each patient account.
  • the healthcare provider accounts may have the unique identifier.
  • associating patient accounts with the healthcare provider account may be performed by the healthcare provider using the healthcare provider computing device, or may be performed by a diabetes management system operator using a web-portal.
  • the information associating healthcare provider accounts with patient accounts may be stored in an appropriate data store.
  • the present technology may identify all of the patient accounts associated with the healthcare provider account as referenced by method box 120. For example, the patient accounts may be filtered out based on the associated healthcare provider account. In addition to being filtered by the healthcare provider, patient accounts can additionally be filtered by diabetes type, geographic location, age, gender, therapy type, user type, etc. As referenced by method box 130, various data synchronization activities, data sharing, and data transfers between accounts may be interrupted, stopped, and/or disabled, by the account manager, between the healthcare provider account and the diabetes management system, as well as each of the identified patient accounts.
  • Data synchronization activities may include, but are not limited to, processes of establishing consistency among data between patient accounts and the healthcare provider account, and the continuous harmonization of the data over time. These activities may include synchronizing files; data; updates; settings; preferences; formats; statistics; usage information; device information; configurations; messages; notes; etc.
  • data sharing functions may also be stopped and disabled, by the account manager, between the healthcare provider account and the identified patient accounts. Data sharing functions may include, but are not limited to, providing read and/or write functions and access to medical, usage, and personal data; bibliographic information; statistics; etc. between the healthcare provider account and the identified patient accounts and/or patient medical devices.
  • EMR electronic medical records
  • the account manager may deny or remove further access to the data associated with the healthcare provider account, and deactivate certain or all of the patient accounts associated with the healthcare provider account.
  • the methods for managing accounts includes sending, by the account manager, an electronic notification to a person associated with each of the identified patient accounts, such as the patient, where the electronic notification advises the person that the corresponding patient account has been deactivated, and to inform them that the healthcare provider office has stopped data sharing with them.
  • the electronic notification may be via electronic mail or other electronic messaging service.
  • the status of the healthcare provider account may be changed to a "closed" status, and the closure date may be recorded. Messages may be displayed to one or more users informing them that the healthcare provider account is closed and all associated patient and user accounts are deactivated.
  • Various audit records and event log entries may be created by the account manager that can be saved and/or archived in a data store within the system, as shown by method box 180, to indicate and memorialize various information related to the closed healthcare provider and/or patient account(s).
  • the web-based portal or web-based application may display a message to inform a user that various accounts are deactivated and that the user details and other identifying features can no longer be edited. It should be understood that various opportunities may be provided throughout this process enabling a user to cancel one or more operations associated with the closing of the accounts.
  • the web-portal may be configured to collect and use geographic locations of the healthcare provider and/or the patients in order to comply with certain regulatory and/or compliance regimes that may exist for different geographic locations, such as different states or countries.
  • different geographic locations may have different requirements concerning the archiving of data related to medical treatment.
  • the computer-implemented methods of the present technology can be configured to archive data associated with each of the plurality of patient accounts and healthcare provider accounts for at least a predetermined period of time.
  • the predetermined period of time may be specifically affiliated with regulations or compliance standards for the geographic location, which may be recorded by the system for each account and managed by the owner of the diabetes management system.
  • Various portions of the data such as references to medical patient data and personal data may be encrypted for patient security and confidentiality.
  • Figure 6 generally represents one non-limiting process associated with the closure or deactivation of a patient account, where the user initiating the closure may be authenticated as a healthcare provider.
  • an account manager can receive a request to deactivate or close a specific patient account associated with a healthcare provider, or a healthcare provider account.
  • the method may include various confirmations of the deactivation request or authenticate the request as previously described above and noted by method box 210.
  • the computer-implemented system may display a warning message that any active sessions of the deactivated user will be terminated.
  • a specific confirmation may optionally be solicited by the account manager, seeking confirmation of the request to close the patient account.
  • the patient account may then be deactivated and closed upon receipt of the confirmation of the request as depicted in method box 240.
  • method box 250 indicates that an electronic notification may be sent by the account manager to a person, such as a patient, associated with the patient account to advise the person that the corresponding patient account has been or will be deactivated and/or closed.
  • Certain data associated with the patient account may be archived as noted in method box 260.
  • the archived data may be stored for a predetermined period of time as discussed above.
  • Appropriate audit records and event log entries documenting the deactivation of the patient account may be created as referenced by method box 270.
  • the patient account may be associated with a portable medical device, for example, having a unique serial number or identifier associated with the account.
  • Methods according to the present technology may include disabling, by the account manager, data transfer activities associated with the portable medical device affiliated with a closed or deactivated patient account.
  • Figures 7 - 11 illustrate various graphical user interfaces that may be used in connection with the diabetes management system, portal, and associated software architecture.
  • Figure 7 generally depicts management and viewing options for a web-portal user account. Certain criteria can be selected to narrow down the display of user accounts. By way of example, accounts can be sorted by name, office name, system role, account status, user name, associated email address, and country.
  • Figure 8 generally depicts the configuration and selection of accounts assigned with countries and/or geographic regions. For example, certain healthcare provider (caregiver) accounts or patient (personal) accounts can be filtered by their association with certain countries and/or geographic regions.
  • Figures 9 and 10 generally depict additional settings and preferences that may be associated with accounts linked with a specific country or geographic region. As shown, Figure 9 provides a variety of regional settings such as language, time zone and time/date formats, measurement units, logos, color and background selections, and the like. Figure 10 provides configurations for the deletion period for closed accounts, optional selection of research candidates, notations regarding minimum age requirements for account holders, and the like. Figure 10 also provides optional information regarding medical device/product information, registration information, and End User License Agreements.
  • Figure 11 provides an exemplary user interface for an event log.
  • each event log record can include various bibliographic information, as well as description fields that display event types, names, details, user names and office names/locations.
  • the techniques described herein may be implemented by one or more computer programs executed by one or more processors.
  • the computer programs include processor-executable instructions that are stored on a non-transitory tangible computer readable medium.
  • the computer programs may also include stored data.
  • Non-limiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.
  • the present disclosure also relates to an apparatus for performing the operations herein.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer.
  • a computer program may be stored in a tangible computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Biomedical Technology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Tourism & Hospitality (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Child & Adolescent Psychology (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)

Claims (22)

  1. Sicherheitssystem für medizinische Daten, umfassend:
    - eine tragbare medizinische Vorrichtung (28) zum Messen medizinischer Parameter, die auf einen physiologischen Zustand eines Säugers hinweisen; und
    - eine Servervorrichtung (18), wobei die Servervorrichtung eine Speichervorrichtung umfasst und/oder funktionsfähig damit verbunden ist, wobei die Servervorrichtung einen Buchhaltungsmanager eines-Pflegemanagementsystem-Managementsystems beherbergt, wobei der Buchhaltungsmanager zum Verwalten der Konten konfiguriert ist, die in der Speichervorrichtung gespeichert sind, wobei die Konten ein erstes Konto, das mit einem Gesundheitsdienstleister verbunden ist, und eine Mehrzahl von Patientenkonten, die mit dem ersten Konto verbunden sind, umfasst, wobei jedes Patientenkonto medizinische Daten eines jeweiligen Patienten umfasst;
    - ein Mobilgerät (20), das ein Anwendungsprogramm (32) beherbergt, wobei das Anwendungsprogramm mit der tragbaren medizinischen Vorrichtung und mit dem Buchhaltungsmanager zusammenarbeitsfähig ist, wobei das Mobilgerät mit der Servervorrichtung über ein Netzwerk (16) verbunden ist,
    wobei die tragbare medizinische Vorrichtung zum wiederholten Messen medizinischer Parameter eines der Patienten konfiguriert ist;
    wobei das Anwendungsprogramm zu wiederholten und voll automatischen Aufnehmen der gemessenen medizinischen Parameter von der Messvorrichtung konfiguriert ist und zum sofortigen Weiterleiten der aufgenommenen, gemessenen medizinischen Parameter zu dem Buchhaltungsmanager zum Speichern der Parameter in der Speichervorrichtung des Servers als Teil der Patientenbuchhaltung des Patienten konfiguriert ist,
    dadurch gekennzeichnet, dass
    die tragbare medizinische Vorrichtung, das Anwendungsprogramm und der Buchhaltungsmanager derart konfiguriert sind, dass nur eine einzige Kopie der gemessenen medizinischen Daten auf Dauer in der Speichervorrichtung gespeichert wird und derart, dass irgendwelche vorübergehend gebildeten Kopieren der gemessenen medizinischen Daten sofort von der tragbaren medizinischen Vorrichtung und dem Mobilgerät in nach Ausführen des Weiterleitens gelöscht werden,
    wobei der Buchhaltungsmanager konfiguriert ist, die folgenden Schritte auszuführen:
    - Aufnehmen einer Anforderung, ein erstes Konto zu deaktivieren;
    - Entfernen von Zugang zu Daten, die mit dem ersten Konto verbunden sind;
    - Identifizieren jedes der Patientenkonten, die mit dem ersten Konto verbunden sind und Deaktivieren jedes der identifizierten Patientenkonten;
    - Senden einer elektronischen Benachrichtigung an die Patienten, die mit jedem der identifizierten Patientenkonten verbunden sind, wobei die elektronische Benachrichtigung den Patienten verständigt, dass das entsprechende Patientenkonto deaktiviert worden ist;
    - Schaffen eines Prüfprotokolls in einem Datenspeicher, wo das Prüfprotokoll die Deaktivierung des ersten Kontos anzeigt; und
    - Senden eines Beendigungsbefehls an das Anwendungsprogramm der Patienten, die mit jedem der identifizierten Patientenkonten verbunden sind, wobei die Anwendungsprogramme so konfiguriert sind, dass sie das Weiterleiten medizinischer Messdaten zum Buchhaltungsmanager auf das Erhalten des Beendigungsbefehls hin sofort beendigen.
  2. Sicherheitssystem nach Anspruch 1,
    - wobei die tragbare medizinische Vorrichtung einen Prozessor und eine Schnittstelle zum Austauschen von Daten mit dem Anwendungsprogramm umfasst; und
    - wobei die Schnittstelle in der Lage ist, die tragbare medizinische Vorrichtung mit dem Anwendungsprogramm (32) zu paaren;
    - wobei in einem gepaarten Zustand die tragbare medizinische Vorrichtung und das Anwendungsprogramm (32) über eine Datenkommunikationsverbindung verbunden sind; und
    - wobei die eine tragbare medizinische Vorrichtung nur im gepaarten Zustand zum Ermöglichen einer Übertragung von Messdaten an das Anwendungsprogramm konfiguriert ist.
  3. Sicherheitssystem nach irgendeinem der vorhergehenden Ansprüche, wobei das Anwendungsprogramm zum Ausführen von Schritten konfiguriert ist, umfassend:
    - das Aufnehmen eines Paarungsbefehls vom Patienten über eine Benutzerschnittstelle oder von der tragbaren medizinischen Vorrichtung;
    - als Reaktion auf das Aufnehmen des Paarungsbefehls, Anfordern einer Vorrichtungs-ID von der tragbaren medizinischen Vorrichtung;
    - als Reaktion auf die Anforderung, Aufnehmen der Vorrichtungs-ID von der tragbaren medizinischen Vorrichtung;
    - Beurteilen der aufgenommenen Vorrichtungs-ID zum Bestimmen, ob eine Paarung zwischen dem Anwendungsprogramm und der medizinischen Messvorrichtung schon mindestens einmal vorher festgelegt worden ist;
    - nur wenn bestimmt wird, dass die Paarung zwischen dem Anwendungsprogramm und der medizinischen Messvorrichtung schon mindestens einmal vorher festgelegt worden ist, automatisches Festlegen der Paarung in Zusammenarbeit mit der tragbaren medizinischen Vorrichtung, durch Schaffen der Datenkommunikationsverbindung; und automatisch Durchführen des Weiterleitens der Messdaten;
    - nur wenn bestimmt wird, dass die Paarung zwischen dem Anwendungsprogramm und der medizinischen Messvorrichtung noch nicht mindestens einmal vorher festgelegt worden ist, automatisches Senden einer Vorrichtungregistrieranforderung an den Buchhaltungsmanager, wobei die Vorrichtungregistrieranforderung die aufgenommene Vorrichtung-ED und eine Patienten-ID des Patienten, der die Mobilvorrichtung benutzt, umfasst;
    und nur Ausführen des Weiterleitens der Messdaten, nachdem eine Bestätigung vom Buchhaltungsmanager aufgenommen worden ist, dass die tragbare medizinische Vorrichtung für den Patienten erfolgreich beim Buchhaltungsmanager registriert worden ist.
  4. Sicherheitssystem nach Anspruch 3, wobei das Anwendungsprogramm derart konfiguriert ist, dass
    - als Reaktion auf das Aufnehmen der Bestätigung von dem Buchhaltungsmanager, dass die tragbare medizinische Vorrichtung erfolgreich für den Patienten beim Buchhaltungsmanager registriert worden ist, permanent Speichern der Vorrichtungs-ID in einem Speichermedium der Mobilvorrichtung als Bezugswert in Verbindung mit der Bestätigung des Buchhaltungsmanagers; und
    - mit Bezug auf das Aufnehmen eines späteren Paarungsbefehls, Bestimmen, durch Vergleichen der gespeicherten Bezugsvorrichtungs-ID mit einer Vorrichtungs-ID, die von der medizinischen Messvorrichtung aufgenommen worden ist, dass eine Paarung zwischen dem Anwendungsprogramm und der medizinischen Messvorrichtung schon festgestellt worden ist.
  5. Sicherheitssystem nach irgendeinem der Ansprüche 3 - 4, wobei das Anwendungsprogramm derart konfiguriert ist, dass das Aufnehmen der Vorrichtungs-ID von der tragbaren medizinischen Vorrichtung Folgendes umfasst:
    - Aufnehmen einer Nachricht von der tragbaren medizinischen Vorrichtung, das keine Vorrichtungs-ID zu dem Anwendungsprogramm zurückgeschickt werden kann;
    - automatisches Schaffen einer willkürlichen Zeichenfolge;
    - Zurückschicken der gebildeten willkürlichen Zeichenfolge zu der tragbaren medizinischen Vorrichtung zur Speicherung auf Dauer in einem Speicher der tragbaren medizinischen Vorrichtung als Vorrichtungs-ID der Messvorrichtung;
    - Benutzen der geschaffenen willkürlichen Zeichenfolge als aufgenommene Vorrichtungs-ID.
  6. Sicherheitssystem nach einem der Ansprüche 3 - 5, wobei der Buchhaltungsmanager derart konfiguriert ist, dass das erfolgreiche Registrieren der tragbaren medizinischen Vorrichtung beim Buchhaltungsmanager folgendes umfasst:
    - Authentifizierung des Patienten;
    - Aufnehmen einer Bestätigung von dem authentifizierten Patienten, dass die tragbare medizinische Vorrichtung, die durch die Vorrichtungs-ID in der Vorrichtungsregistrieranforderung identifiziert worden ist, registriert werden soll;
    - wenn die Bestätigung aufgenommen worden ist, Speichern der Vorrichtungs-ID, die in der Vorrichtungregistrieranforderung enthalten ist, durch den Buchhaltungsmanager in Verbindung mit der Patienten-ID in der Vorrichtungsregistrieranforderung, wobei die Patienten-ID das Patientenkonto des Patienten identifiziert.
  7. Sicherheitssystem nach irgendeinem der Ansprüche 1 - 6,
    - wobei der Buchhaltungsmanager derart konfiguriert ist, dass nur Messdaten, die durch eine tragbare medizinische Vorrichtung erfasst worden und erfolgreich durch den Buchhaltungsmanager registriert worden sind, in Verbindung mit einem jeweiligen Patientenkonto aufgenommen und gespeichert werden und/oder
    - wobei das Anwendungsprogramm derart konfiguriert ist, dass nur Messdaten, die durch eine tragbare medizinische Vorrichtung erfasst worden und erfolgreich beim Buchhaltungsmanager registriert worden sind, zu dem Buchhaltungsmanager weitergeleitet werden.
  8. Sicherheitssystem nach irgendeinem der vorhergehenden Ansprüche, wobei die medizinische Messvorrichtung eine Glucosemessvorrichtung ist.
  9. Sicherheitssystem nach irgendeinem der vorhergehenden Ansprüche, wobei der Buchhaltungsmanager konfiguriert ist, auf das Aufnehmen der Anforderung, das Konto zu deaktivieren, die folgenden Schritte auszuführen:
    - Sperren der Datensynchronisierungsfunktionen, wobei die Datensynchronisierungsfunktionen konfiguriert sind, die Daten zwischen einer ersten und einer zweiten Speichervorrichtung auszutauschen, wobei die ausgetauschten Daten zum ersten Konto und/oder einem der identifizierten Patientenkonten gehören, wobei die erste Speichervorrichtung Teil der Servervorrichtung und/oder funktionsfähig damit verbunden ist, wobei die zweite Speichervorrichtung Teil der medizinischen Messvorrichtung ist und/oder
    - Sperren der Datenmitbenutzungsfunktionen, wobei die Datenmitbenutzungsfunktionen konfiguriert sind, Daten zwischen dem ersten Konto und jedem der identifizierten Patientenkonten auszutauschen, wobei die Daten, die zu dem ersten Konto und zu den identifizierten Patientenkonten gehören, in einer Speichervorrichtung gespeichert werden, die Teil der Servervorrichtung oder funktionsfähig damit verbunden ist.
  10. Mit dem Computer ausgeführtes Verfahren zum Verwalten von Konten in einem Diabetes-Managementsystem, wobei das Verfahren in einem Sicherheitssystem nach irgendeinem der Ansprüche 1 - 9 ausgeführt wird, wobei das Verfahren Folgendes umfasst:
    - Aufnehmen, durch den Buchhaltungsmanager, der Anforderung, das erste Konto zu deaktivieren, das mit einem Gesundheitsdienstleister verbunden ist, wobei der Buchhaltungsmanager als durch einen Computer ausführbare Anweisungen ausgeführt wird, die in einem Computerprozessor der Servervorrichtung (18) ausgeführt werden;
    - Entfernen, durch den Buchhaltungsmanager, von Zugang zu Daten, die mit dem ersten Konto verbunden sind;
    - Identifizieren, durch den Buchhaltungsmanager, jedes der Patientenkonten, die mit dem ersten Konto verbunden sind, und Deaktivieren jedes der identifizierten Patientenkonten;
    - Senden, durch den Buchhaltungsmanager, der elektronischen Benachrichtigung an die Person, die mit jedem der identifizierten Patientenkonten verbunden ist, wobei die elektronische Benachrichtigung die Person verständigt, dass das entsprechende Patientenkonto deaktiviert worden ist; und
    - Schaffen, durch den Buchhaltungsmanager, eines Prüfprotokolls in einem Datenspeicher, wo das Prüfprotokoll die Deaktivierung des ersten Kontos anzeigt; und
    - Senden, durch den Buchhaltungsmanager, eines Beendigungsbefehls an das Anwendungsprogramm der Patienten, die mit jedem der identifizierten Patientenkonten verbunden sind, wobei die Anwendungsprogramme so konfiguriert sind, dass sie das Weiterleiten medizinischer Messdaten zum Buchhaltungsmanager auf das Erhalten des Beendigungsbefehls hin sofort beendigen.
  11. Verfahren nach Anspruch 10, ferner das Archivieren von Daten, die mit jedem der Vielzahl von Patientenkonten verbunden sind, für eine vorbestimmte Zeitperiode umfassend.
  12. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 11, ferner das Sperren, durch den Buchhaltungsmanager, der Datensynchronisierungsfunktionen umfassend, wobei die Datensynchronisierungsfunktionen konfiguriert sind, Daten zwischen einer ersten und einer zweiten Speichervorrichtung auszutauschen, wobei die ausgetauschten Daten zum ersten Konto und/oder einem der identifizierten Patientenkonten gehören, wobei die erste Speichervorrichtung Teil der Servervorrichtung und/oder funktionsfähig damit verbunden ist, wobei die zweite Speichervorrichtung Teil einer medizinischen Vorrichtung ist.
  13. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 13, ferner das Sperren, durch den Buchhaltungsmanager, Datenmitbenutzungsfunktionen umfassend, wobei die Datenmitbenutzungsfunktionen konfiguriert sind, Daten zwischen dem ersten Konto und jedem der identifizierten Patientenkonten auszutauschen, wobei die Daten, die zu dem ersten Konto und zu den identifizierten Patientenkonten gehören, in einer Speichervorrichtung gespeichert werden, die Teil der Servervorrichtung oder funktionsfähig damit verbunden ist.
  14. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 13, ferner das Authentifizieren, durch den Buchhaltungsmanager, der Anforderung umfassend, das erste Konto, das mit dem Gesundheitsdienstleister verbunden ist, zu deaktivieren und nur das erste Konto in dem Fall zu deaktivieren in dem die Anforderung erfolgreich authentifiziert worden ist.
  15. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 14, umfassend:
    - Aufnehmen, durch den Buchhaltungsmanager, einer Anforderung, ein Patientenkonto zu deaktivieren, das mit dem Diabetes-Pflegemanagementsystem verbunden ist;
    - Bereitstellen, durch den Buchhaltungsmanager, einer Warnnotifizierung, dass aktive Perioden des Patientenkonto beendet werden,
    - Erbitten, durch den Buchhaltungsmanager, einer Bestätigung der Anforderung, das Patientenkonto zu deaktivieren;
    - Deaktivieren des Patientenkontos nach Aufnahme der Bestätigung der Anforderung, das Patientenkonto zu deaktivieren;
    - Senden, durch den Buchhaltungsmanager, einer elektronischen Benachrichtigung an den Gesundheitsdienstleister, dessen erstes Konto mit dem Patientenkonto verbunden ist, wobei die elektronische Benachrichtigung die Person in Kenntnis setzt, dass das entsprechende Patientenkonto deaktiviert worden ist; und
    - Schaffen, durch den Buchhaltungsmanager, eines Prüfprotokolls in einem Datenspeicher, wo das Prüfprotokoll die Deaktivierung des Patientenkontos anzeigt.
  16. Verfahren nach irgendeinem der Ansprüche 10 - 15, wobei zwei oder mehr der Patientenkonten jeweils mit einer tragbaren medizinischen Vorrichtung verbunden sind, wobei das Verfahren ferner die folgenden Schritte umfasst, die durch den Buchhaltungsmanager ausgeführt werden sollen:
    - Aufnehmen einer Anforderung, alle tragbaren medizinischen Vorrichtungen eines spezifischen Vorrichtungstyps und/oder einer spezifischen Vorrichtungstypversion zu deaktivieren, wobei die Anforderung eine Vorrichtungstyp-ID und/oder eine Vorrichtungstypversion umfasst;
    - Identifizieren aller Patientenkonten, denen eine Vorrichtungs-ID einer tragbaren medizinischen Vorrichtung des Typs oder der Version, der/die in der Anforderung angegeben ist, zugeordnet ist;
    - Deaktivieren und Löschen, im Register, der Vorrichtungen, deren Typ und/oder Version in der Anforderung angegeben ist, in den identifizierten Patientenkonten;
    - Senden einer elektronischen Benachrichtigung an die Patienten der identifizierten Patientenkonten, wobei die elektronische Benachrichtigung die Person verständigt, dass die entsprechende tragbare medizinische Vorrichtung im Register gelöscht worden ist und/oder eine Firmwareaktualisierung benötigt.
  17. Verfahren nach irgendeinem der Ansprüche 10 - 16, wobei mindestens ein Teil der Daten verschlüsselt ist.
  18. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 17, wobei die Anforderung, das Patientenkonto zu deaktivieren, vom ersten Gesundheitsdienstleisterkonto stammt und mit dem Patientenkonto verbunden ist.
  19. Verfahren nach irgendeinem der vorhergehenden Ansprüche 15 - 18, wobei die elektronische Benachrichtigung einem Patienten bereitgestellt wird, der mit dem Patientenkonto verbunden ist.
  20. Verfahren nach irgendeinem der vorhergehenden Ansprüche 15 - 19, ferner das Authentifizieren, durch den Buchhaltungsmanager, der Anforderung, das Patientenkonto zu deaktivieren, vordem Deaktivieren des Patientenkontos, und nur das Patientenkontos in dem Fall zu deaktivieren, dass die Anforderung erfolgreich authentifiziert worden ist, umfassend .
  21. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 20, wobei das Patientenkonto mit einer tragbaren medizinischen Vorrichtung verbunden ist und das Verfahren ferner das Sperren, durch den Buchhaltungsmanager, der Datenübertragung zwischen der tragbaren medizinischen Vorrichtung und dem Patientenkonto auf ein Deaktivieren des Patientenkontos hin umfasst, wobei Patientendaten, die zu dem Patientenkonto gehören, in einem Speichermedium gespeichert werden, das zur Servervorrichtung gehört und/oder funktionsfähig damit verbunden ist.
  22. Verfahren nach irgendeinem der vorhergehenden Ansprüche 10 - 21, ferner Folgendes umfassend:
    - Sperren, durch den Buchhaltungsmanager, der Datenübertragung zwischen einem elektronischen medizinischen Dokumentationssystem und dem Patientenkonto auf eine Deaktivierung des Patientenkontos hin, wobei Patientendaten, die zu dem Patientenkonto gehören, in einem Speichermedium gespeichert werden, das zu der Servervorrichtung gehört und/oder funktionsfähig damit verbunden ist; und
    - Bereitstellen, durch den Buchhaltungsmanager, einer Möglichkeit, die Anforderung, das Patientenkonto zu deaktivieren, zu widerrufen.
EP14727716.4A 2013-04-26 2014-04-24 Sicherheitssystem mit kontomanager für eine tragbare medizinische vorrichtung Active EP2989576B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP18187339.9A EP3462457B1 (de) 2013-04-26 2014-04-24 Sicherheitssystem mit tragbarer medizinischer vorrichtung

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361816636P 2013-04-26 2013-04-26
US14/172,585 US9830673B2 (en) 2013-04-26 2014-02-04 System portal control for a diabetes management system
PCT/EP2014/058388 WO2014174038A2 (en) 2013-04-26 2014-04-24 Security system with portable medical device

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP18187339.9A Division EP3462457B1 (de) 2013-04-26 2014-04-24 Sicherheitssystem mit tragbarer medizinischer vorrichtung

Publications (2)

Publication Number Publication Date
EP2989576A2 EP2989576A2 (de) 2016-03-02
EP2989576B1 true EP2989576B1 (de) 2018-08-22

Family

ID=51789985

Family Applications (2)

Application Number Title Priority Date Filing Date
EP14727716.4A Active EP2989576B1 (de) 2013-04-26 2014-04-24 Sicherheitssystem mit kontomanager für eine tragbare medizinische vorrichtung
EP18187339.9A Active EP3462457B1 (de) 2013-04-26 2014-04-24 Sicherheitssystem mit tragbarer medizinischer vorrichtung

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP18187339.9A Active EP3462457B1 (de) 2013-04-26 2014-04-24 Sicherheitssystem mit tragbarer medizinischer vorrichtung

Country Status (5)

Country Link
US (1) US9830673B2 (de)
EP (2) EP2989576B1 (de)
ES (2) ES2690354T3 (de)
PT (1) PT2989576T (de)
WO (1) WO2014174038A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9814850B2 (en) * 2012-06-08 2017-11-14 Koninklijke Philips N.V. Patient sleep therapy self management tool
CN116206744A (zh) * 2015-06-25 2023-06-02 甘布罗伦迪亚股份公司 具有分布式数据库的医疗装置系统和方法
WO2018125841A1 (en) * 2016-12-27 2018-07-05 Dexcom, Inc. Systems and methods for patient monitoring using an hcp - specific device
US20230343424A1 (en) * 2022-04-26 2023-10-26 Implicity System for monitoring health data acquisition devices

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010032099A1 (en) * 1999-12-18 2001-10-18 Joao Raymond Anthony Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5997476A (en) 1997-03-28 1999-12-07 Health Hero Network, Inc. Networked system for interactive communication and remote monitoring of individuals
US7734656B2 (en) 1998-02-24 2010-06-08 Luc Bessette System and method for electronically managing medical data files in order to facilitate genetic research
US6024699A (en) 1998-03-13 2000-02-15 Healthware Corporation Systems, methods and computer program products for monitoring, diagnosing and treating medical conditions of remotely located patients
US6442432B2 (en) 1999-12-21 2002-08-27 Medtronic, Inc. Instrumentation and software for remote monitoring and programming of implantable medical devices (IMDs)
US20020016721A1 (en) 2000-06-05 2002-02-07 Steven Mason System and method for automating record keeping
US20020016718A1 (en) 2000-06-22 2002-02-07 Rothschild Peter A. Medical image management system and method
US7463930B2 (en) 2000-12-20 2008-12-09 Medtronic, Inc. Implantable medical device programmer module for use with existing clinical instrumentation
US7685037B2 (en) * 2001-03-26 2010-03-23 3MFuture Ltd. Transaction authorisation system
US7188151B2 (en) 2001-03-28 2007-03-06 Televital, Inc. System and method for real-time monitoring, assessment, analysis, retrieval, and storage of physiological data over a wide area network
US7103578B2 (en) 2001-05-25 2006-09-05 Roche Diagnostics Operations, Inc. Remote medical device access
EP1490820A4 (de) 2002-03-18 2007-03-21 Merck & Co Inc Computerunterstützter und/oder -implementierter prozess und system zum verwalten und/oder bereitstellen eines portals medizinischer informationen für gesundheitsversorgungsanbieter
US20040167804A1 (en) 2002-04-30 2004-08-26 Simpson Thomas L.C. Medical data communication notification and messaging system and method
US20040167465A1 (en) 2002-04-30 2004-08-26 Mihai Dan M. System and method for medical device authentication
US20130059541A1 (en) * 2003-06-10 2013-03-07 Abbott Diabetes Care Inc. Wireless Communication Authentication for Medical Monitoring Device
CA2858901C (en) * 2004-06-04 2024-01-16 Carolyn Anderson Diabetes care host-client architecture and data management system
US20070100222A1 (en) 2004-06-14 2007-05-03 Metronic Minimed, Inc. Analyte sensing apparatus for hospital use
US8224669B2 (en) * 2004-07-01 2012-07-17 Anchor Holdings, Inc. Chronic disease management system
US9820658B2 (en) 2006-06-30 2017-11-21 Bao Q. Tran Systems and methods for providing interoperability among healthcare devices
US20060184524A1 (en) 2004-09-14 2006-08-17 Gunter Pollanz Method and system for automated data analysis, performance estimation and data model creation
US20080071580A1 (en) 2005-06-03 2008-03-20 Marcus Alan O System and method for medical evaluation and monitoring
US20070192137A1 (en) * 2006-02-01 2007-08-16 Ombrellaro Mark P Access control in an electronic medical record system
US8015067B2 (en) * 2006-02-13 2011-09-06 Google Inc. Deleted account handling for hosted services
US20100223184A1 (en) * 2006-10-11 2010-09-02 Visa International Service Association Sponsored Accounts For Computer-Implemented Payment System
US8316227B2 (en) 2006-11-01 2012-11-20 Microsoft Corporation Health integration platform protocol
CA2567275A1 (en) 2006-11-06 2008-05-06 Saskatchewan Telecommunications Health monitoring system and method
US8281370B2 (en) * 2006-11-27 2012-10-02 Therap Services LLP Managing secure sharing of private information across security domains
US7885712B2 (en) 2006-12-06 2011-02-08 Medtronic, Inc. Medical device programming safety
ES2712778T3 (es) * 2007-05-30 2019-05-14 Ascensia Diabetes Care Holdings Ag Método y sistema para gestionar datos de salud
US8666807B1 (en) * 2008-01-08 2014-03-04 Clear Channel Management Services, Inc. System and method for creating and managing media advertising proposals
US20100188230A1 (en) * 2009-01-29 2010-07-29 Ted Lindsay Dynamic reminder system, method and apparatus for individuals suffering from diminishing cognitive skills
US20100324934A1 (en) 2009-06-23 2010-12-23 Sony Corporation Electronic Backbone for Medicine Infrastructure
US20110165917A1 (en) * 2009-12-31 2011-07-07 Mary Elizabeth Taylor Methods and arrangements employing sensor-equipped smart phones
US20120278094A1 (en) * 2010-10-12 2012-11-01 Rabit Solutions, LLC Methods and systems for health care record, workflow, and billing management using mobile devices
US9292149B2 (en) * 2010-10-22 2016-03-22 Litl Llc Method and apparatus for public computing
US20130229288A1 (en) 2010-11-15 2013-09-05 Lifescan Scotland Limited Server-side initiated communication with analyte meter-side completed data transfer
US8475367B1 (en) * 2011-01-09 2013-07-02 Fitbit, Inc. Biometric monitoring device having a body weight sensor, and methods of operating same
US8630952B2 (en) * 2011-03-04 2014-01-14 Citibank, N.A. Methods and systems using contactless card
US8918651B2 (en) * 2012-05-14 2014-12-23 International Business Machines Corporation Cryptographic erasure of selected encrypted data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010032099A1 (en) * 1999-12-18 2001-10-18 Joao Raymond Anthony Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information

Also Published As

Publication number Publication date
ES2881099T3 (es) 2021-11-26
US20140324464A1 (en) 2014-10-30
EP3462457A1 (de) 2019-04-03
WO2014174038A2 (en) 2014-10-30
EP3462457B1 (de) 2021-05-19
PT2989576T (pt) 2018-10-29
US9830673B2 (en) 2017-11-28
WO2014174038A3 (en) 2015-01-15
ES2690354T3 (es) 2018-11-20
EP2989576A2 (de) 2016-03-02

Similar Documents

Publication Publication Date Title
US10505935B1 (en) Providing notifications to authorized users
KR102549451B1 (ko) 의사가 가치-기반 지불을 위한 품질 측정을 달성하는 것을 돕는 환자-대향 모바일 기술
US10255458B2 (en) Trust based access to records via encrypted protocol communications with authentication system
US11552952B1 (en) Providing notifications to authorized users
US10740845B2 (en) System for mobile device enabled biometric monitoring
US10249386B2 (en) Electronic health records
US10733266B2 (en) Systems and methods of providing patient apps
US20200258605A1 (en) Electronic health records management using wireless communication
US20180137252A1 (en) Patient monitoring systems and methods with event log integration
US20090271221A1 (en) Method and Apparatus for Providing Medical Records Registration
US20160070758A1 (en) System and Method for Multi-Tiered, Rule-Based Data Sharing and Ontology Mapping
US20110112862A1 (en) System and Method for Securely Managing and Storing Individually Identifiable Information in Web-Based and Alliance-Based Networks
US20120023592A1 (en) Medical alert computer interface tamper-proof secure device
US8756076B2 (en) HIPAA-compliant third party access to electronic medical records
WO2021237345A1 (en) Human-centric health record system and related methods
US20190327311A1 (en) Secure access to individual information
EP2989576B1 (de) Sicherheitssystem mit kontomanager für eine tragbare medizinische vorrichtung
JP2015088195A (ja) クラウドベース医療データベースを管理する方法及びそのシステム
JP2010272031A (ja) 携帯電話を用いた双方向的な生活習慣病管理支援システム
CA3137320A1 (en) Human-centric health record system and related methods
CN104106071A (zh) 管理保健服务
US20150127378A1 (en) Systems for storing, processing and utilizing proprietary genetic information
US10102927B2 (en) Systems and methods for storing, processing and utilizing proprietary genetic information
AU2017208567A1 (en) Method for configuring diabetes management device by healthcare provider
Çakmak et al. User privacy in mobile health applications

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151126

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: F.HOFFMANN-LA ROCHE AG

Owner name: ROCHE DIABETES CARE GMBH

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170105

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602014030843

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0019000000

Ipc: G16H0040670000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: G16H 40/67 20180101AFI20180215BHEP

INTG Intention to grant announced

Effective date: 20180308

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1033402

Country of ref document: AT

Kind code of ref document: T

Effective date: 20180915

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602014030843

Country of ref document: DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: FP

REG Reference to a national code

Ref country code: PT

Ref legal event code: SC4A

Ref document number: 2989576

Country of ref document: PT

Date of ref document: 20181029

Kind code of ref document: T

Free format text: AVAILABILITY OF NATIONAL TRANSLATION

Effective date: 20180927

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2690354

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20181120

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20181222

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20181122

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20181122

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20181123

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1033402

Country of ref document: AT

Kind code of ref document: T

Effective date: 20180822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602014030843

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20190523

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190424

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190424

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20140424

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180822

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20240320

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20240320

Year of fee payment: 11

Ref country code: PT

Payment date: 20240322

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20240320

Year of fee payment: 11

Ref country code: FR

Payment date: 20240320

Year of fee payment: 11

Ref country code: BE

Payment date: 20240320

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240320

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20240501

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20240502

Year of fee payment: 11