AUTOMATIC MEDICAL DEVICE PATIENT REGISTRATION

Abstract

A data system (100) is used for managing an information associated with an implantable device (IMP). The data system includes the implantable device. The data system is configured as a distributed database to store the information in two or more nodes of the data system. The implantable device is configured as one of the two or more nodes.

Claims

1. Data system (100) for managing an information associated with an implantable device (IMP), the data system comprising: the implantable device (IMP); wherein the data system is configured as a distributed database to store the information in two or more nodes of the data system; and wherein the implantable device is configured as one of the two or more nodes.

2. The data system according to claim 1, wherein the two or more nodes further comprise the following nodes: a user device (CP) for entering the information into the data system (100); and a backend system (BE).

3. The data system according to claim 2, wherein the user device (CP) comprises: a user interface for receiving the information; a storage unit for storing the information; and a transmitter for transmitting the information to the implantable device (IMP) over an initial communication link (120) between the user device (CP) and the implantable device (IMP) for storing the information in the implantable device.

4. The data system according to claim 3, wherein the data system (100) is configured such that only the user device (CP) is allowed to transmit the information to the implantable device (IMP) for storing the information in the implantable device.

5. The data system according to claim 3, wherein the user device (CP) is further configured to communicate the information to the backend system (BE) over a first communication path (110) for storing the information in the backend system (BE).

6. The data system according to claim 3, wherein the implantable device (IMP) is configured to communicate the information to the backend system (BE) over a second communication path (130, 140) for storing the information in the backend system (BE).

7. The data system according to claim 6, wherein the data system (100) is configured to instruct the implantable device (IMP) to communicate the information over the second communication path, if the first communication path is not available.

8. The data system according to claim 6, wherein the second communication path (130, 140) comprises communication from the implantable device to the backend system via a patient device (PR).

9. The data system according to claim 6, wherein the data system (100) is configured to communicate the information over the second communication path after the initial communication link between the user device (CP) and the implantable device (IMP) is terminated.

10. The data system according to claim 1, wherein the information comprises at least one information entity, wherein the at least one information entity comprises at least one of the following: a patient identifiable information, a patient non-identifiable information, a follow-up information, an implantable device information, or a lead system information.

11. An implantable device (IMP), wherein the implantable device is configured as a node of a distributed database to store an information associated with the implantable device that is also stored in at least one further node of the distributed database.

12. Method for managing an information associated with an implantable device (IMP), wherein the implantable device is part of a distributed database, the method comprising: entering the information into a user device (CP); transmitting the information from the user device to the implantable device over an initial communication link; storing the information in the implantable device; the method further comprising at least one of the following: communicating the information from the user device (CP) to a backend system (BE) over a first communication path; or communicating the information from the implantable device (IMP) to the backend system (BE) over a second communication path.

13. The method according to claim 12, the method further comprising at least one of the following: communicating the information over the second communication path, if the first communication path is not available; or communicating the information over the second communication path after the initial communication link between the user device (CP) and the implantable device (IMP) is terminated.

14. The method according to claim 12, the method further comprising at least one of the following: relating information entities which are comprised in the information to each other; or relating at least one information entity which is comprised in the information to at least one supplementary information entity which is comprised in the data system (100).

15. The method according to claim 12, the method further comprising at least one of the following: communicating the information from the implantable device (IMP) to the backend system (BE) over the second communication path via a patient device (PR); relating a patient device to the implantable device; relating a patient device to the information; or relating a patient device to at least one information entity.

Description

DESCRIPTION OF THE DRAWINGS

[0049] In the following, the Figures of the present disclosure are listed:

[0050] FIG. 1 Schematic representation of an exemplary embodiment of a data system according to the present invention.

[0051] FIGS. 2a-b Schematic representation of an exemplary embodiment of a user interface of a user device in the data system for entering information associated with an implantable device.

[0052] FIG. 3 Schematic representation of an exemplary embodiment of a user interface of a user device in the data system showing a patient assignment form.

[0053] FIGS. 4a-b Schematic representations of an exemplary embodiment of a user interface of a user device in the data system showing a patient assignment search form.

DETAILED DESCRIPTION

[0054] FIG. 1 shows a schematic representation of an exemplary embodiment of a data system 100 according to the present invention. The data system 100 may comprise various nodes which may be communicatively interconnected. For example, the nodes of the data system 100 may comprise a user device CP, an implantable device IMP, a patient device PR, and/or a backend system BE. The user device CP may be a portable device (e.g. a tablet, a smartphone, etc.) and/or a stationary device (e.g. a desktop PC, a stationary medical device, etc.).

[0055] The implantable device IMP may comprise any implantable (medical) device (e.g. a pacemaker, a cardioverter-defibrillator, a cardiac monitor, a (neuro)stimulator, a spinal cord stimulator, an implantable sensor, a trial stimulator, etc.). Hence, the implantable device IMP may be implanted into a patient wherein the implantable device IMP may be configured as a node of the data system 100. The implantable device IMP may thus communicate with another node of the data system 100 that may reside outside of the patient's body (and/or another node residing inside of the patient).

[0056] The patient device PR may comprise a portable remote (comprising a user interface e.g. a keyboard, a display, a touchscreen, etc.) which may be operated by the patient. In an example, the patient device PR may comprise a transceiver for relaying the communication from the implantable device IMP to the other nodes of the data system 100.

[0057] The backend system BE may comprise various components (e.g. supplementary nodes implemented by hardware and/or software) and may be configured to enable various peripheral data operations, as outlined herein (e.g. further data storage, data analysis, management of the nodes of the data system 100, cryptographic operations, data log management, authentication processes, monitoring data of the nodes of the data system, remote monitoring of the implantable device IMP, etc.). Furthermore, the backend system BE may comprise various components to deliver a server-side functionality to the data system (e.g. a (database) server, a synchronization interface for coupling the information to the backend system's storage, etc.). In an example, the backend system may be accessed by addressing an according server uniform resource locator (URL). In an example, the backend system BE may comprise a service center SC which may function as a central data processing system to implement the main control/access unit of the backend system BE (e.g. the service center may trigger/control various components of the backend system to provide the needed functionality depending on a specific communication from the other nodes of the data system to the service center SC, etc.). When referring to the backend system BE it may also be understood as referring to the service center SC (comprised in the backend system BE) since the service center may control most operations that take place in the backend system BE. For example, the backend system BE may be configured to implement an authentication of the patient device (e.g. via the open-source solution Keycloak), an authentication of the clinician by an identity and access management (e.g. via the commercial solution Azure AD (which may be hosted by the company Microsoft)), a system for data replication between the nodes of the data system 100 (e.g. between the user device CP, the patient device PR and/or the service center SC) wherein the system for data replication may be implemented by open-source solution Couchbase (e.g. a Couchbase server comprised in the backend system BE), for example. The backend system may be further configured for alerting of mobile apps and/or mobile devices (e.g. which may be implemented by the commercial solution Firebase Cloud Messaging (which may be hosted by the company Google)).

[0058] In a further example, the data system 100 may comprise an application that may allow viewing, printing and/or exporting patient data and/or patient reports or other information stored in the distributed database (referred to as print application herein). In an example, the print application may be regarded as a virtual user device and may be referred to as a virtual node of the data system 100. The print application may be implemented by software (e.g. a computer program, an executable application, which may be accessed via a desktop computer, a mobile device, e.g., a (real) node of the data system 100). In an example, the print application may be accessible over the backend system BE, the user device CP and/or other data consumers of the backend system BE. The print application may allow viewing of the information (e.g. patient data) which is stored in a node of the data system 100 (e.g. the information in the user device CP, the backend system BE, the service center SC, etc.). In addition, it may allow printing and/or exporting the information (e.g. the patient reports). As an example, the data system 100 may thus comprise a printer (as a node) for printing the information. The exported information may be arranged in a specific report structure (e.g. for any easy readout) wherein various file formats may be conceivable of the exported information (e.g. a portable document format file, i.e. a PDF file, a txt file, a word processing format, etc.) wherein the exported information may be stored in the data system 100 and/or may be sent to another node of the data system 100 (or to an external device not comprised in the data system).

[0059] The nodes of the data system may be communicatively coupled by a wireless connection (e.g. via electro-magnetic waves, over Bluetooth, Wi-Fi, RF, etc.) and/or via a wired connection. For example, the communicative coupling between the nodes of the data system 100 may be implemented by public connectivity networks (e.g. public Wi-Fi, communication over the internet protocol) to enable an optimum communication access throughout the application.

[0060] In an example, each node may be directly communicatively coupled (e.g. via a direct connection) to every other node of the system via a direct communication path. In another example, as outlined in FIG. 1, the following node pairs may be configured for a direct communication: the user device CP and the backend system BE (via a communication path 110), the user device CP and the implantable device IMP (via a communication path 120 that may be referred to as an initial communication link), the implantable device IMP and the patient device PR (via a communication path 130), the patient device PR and the backend system BE (via a communication path 140), the user device CP and the patient device PR (via a communication path 150). The user device CP may be operated by a clinician C who may enter information into the user device CP and/or may read out information displayed on the user device CP (as indicated by the line C-CP in FIG. 1). The patient device PR may be operated by a patient P for adjusting implant settings (e.g. a neurostimulation parameter, a neurostimulation mode) (as indicated by the line P-PR in FIG. 1).

[0061] The data system 100 may be configured as a distributed database wherein each node of the data system 100 may comprise a database of the distributed database for storing information associated with the implantable device IMP. In an example, the data system 100 may be configured such that each node in the data system 100 may comprise (e.g. may store) the same information. The data system 100 (configured according to the principles of a distributed database) may thus ensure that a newly created information and/or an update of an existing information at any node may be replicated through the remaining nodes of the data system 100 (as outlined herein). This may be enabled by the interconnective character of the nodes in the data system 100 which is provided by the communicative coupling between the nodes.

[0062] In an example, the user device CP may be the only entry point for entering an information associated with the implantable device IMP to the data system 100. In an example, for entering the information over the user device CP, it may be mandatory (by the data system's 100 design) that the user device CP is communicatively coupled to the implantable device IMP over an initial communication link (e.g. the communication path 120, as outlined in FIG. 1). The user device CP that is currently in-session with the implantable device IMP (e.g. over the communication path 120) may be the only node of the data system that is allowed to create and/or edit/update the information associated with the implantable device IMP stored in the distributed database. The user device CP may initially create information entities (e.g. patient entities) corresponding to the entered information associated with the implantable device IMP. The information may comprise the patient identifiable information, the patient non-identifiable information, and/or connected entities like a follow-up information, and implantable device information, a lead system information, etc., as outlined herein. In general, the information may comprise patient data for mapping the implantable device IMP to the patient having the implantable device IMP. In particular, the information may be entered to the data system (over the user device CP) when a new patient is registered to the implantable device. Subsequently, the user device CP may store the information (e.g. the information entities) in its own local database and transmit the information (e.g. over the communication path 120) to the implantable device IMP for storing it in the implantable device's IMP memory. The transmitting of the information to the implantable device IMP may be triggered immediately with the storing of the information in the user device CP.

[0063] This approach may ensure that data entry points to the data system 100 are limited to a minimum (e.g. only the user device CP) which may reduce system complexity, reduce erroneous and/or varying information throughout the data system, enable an optimized patient registration, reduce medical risks resulting from a false patient association to the implantable device IMP, etc. Moreover, this approach may ensure that the information can only be entered redundantly into two nodes of the data system (i.e. the implantable device CP and the patient device IMP). The newly created (or edited/updated) information entities may thus be (almost) instantly available at these two nodes (and thus database storage locations) wherein said two nodes may be referred to as the two origin nodes.

[0064] Subsequently, the information may be replicated through the nodes of the data system 100 over various paths to synchronize and/or align the information throughout the distributed database. For most application purposes, it may be necessary to replicate the information from the two origin nodes to the backend system BE (to enable the peripheral data applications as outlined herein). To that regard, the invention may enable two redundant paths for data replication of the entered information (at the two origin nodes).

[0065] In a first case, if the user device CP and the backend system BE (or in particular the service center SC) may have an available communication path (e.g. the direct communication path 110) when the information entities are created, the user device CP may replicate these information entities directly to a storage medium in the backend system BE (e.g. to a storage server, e.g. a Couchbase server) via this available communication path. For example, the communication path 110, which can be used in this case, may be referred to as a first communication path. In an example, the user device CP may use a replication process optimized for the storage medium in the backend system BE (e.g. a Couchbase Lite to Sync Gateway replication process if the storage medium is a Couchbase server) to push the documents to the backend system (or the service center SC). To that regard, the user device CP may have to be online (e.g. able to connect to the communicative coupling) and the backend system may have to be accessible (e.g. ready for data communication).

[0066] However, e.g., if the user device CP is offline when the information entities are created, the prior case of replication may not occur. In this situation (i.e. a second case), the information redundancy (due to the two origin nodes) in combination with the communication path redundancy to the backend system BE (which is available through the various interconnected nodes of the data system) may ensure an undisturbed replication of the data to the backend system BE, regardless. For example, the redundant communication to the backend system BE in the second case may comprise communication via the communication path 130, the patient device PR, and the communication path 140. To that regard, this (second case) redundant communication path may be referred to as the second communication path. Notably, in this case the implantable device IMP (as one of the two origin nodes) may transmit the information entities in an encrypted Home Monitoring (HM) message (e.g. in an implant encrypted message, such as an implant encrypted message document) to the patient device PR, which in turn may replicate the HM message to the backend system BE (e.g. to the Couchbase server). In the backend system BE, the encrypted HM message may be decrypted, parsed and/or processed. During parsing, the individual data blocks/parameters may be extracted from the message. During processing, the patient entities may be re-assembled from the message and written to the storage medium in the backend system BE.

[0067] In an example, the message parsing and message processing may be implemented in a model driven manner. For example, the backend system BE may comprise machine-readable models that define a model data structure (e.g. the raw/original structure of the information) and the corresponding (structure of the) information entity that is accordingly to be re-assembled. Hence, when a message comprising the information arrives in the backend system BE, the backend system BE may interpret said information into a (pre)defined structure of the information entity. This may be advantageous when a later generation (or a different type) of the implantable device IMP sends the information to the backend system BE in a different way (e.g. in a different raw/original structure). In that case, an additional machine-readable model may be simply added to the backend system BE wherein the additional machine-readable model may be configured for interpreting the different data structure into the existing structure of the according information entity. Hence, the information will be stored in the same structure in the backend system BE, regardless of the transmitted data structure. This approach may significantly reduce coding complexity and may minimize erroneous data.

[0068] In general, the HM Messages may be triggered at least once a day or based on additional triggers. In an example of the data system, the HM message may be triggered as soon as a connection between the user device CP and the implantable device IMP is terminated. This may ensure, that the redundant communication (via the second communication path) may be immediately initiated since a termination of the coupling (of the user device and the implantable device may indicate a new/updated information entry to the data system 100). In another example, a trigger for sending the HM message (comprising the information associated with the implantable device IMP) may be based on an actual storing of newly created (or updated) information in the implantable device IMP. Hence, if the user device CP has transmitted the information to the implantable device IMP (which in turn resulted in storing the information in the implantable device), the patient device PR and the implantable device IMP may connect (e.g. wirelessly via Bluetooth) wherein the IMP may produce an HM message which may be transmitted to the backend system BE via the second communication path. In a further example, a trigger for sending the HM message (comprising the information associated with the implantable device IMP) may be based on an event in which a connection to the patient device PR has been established (e.g. when the patient manually establishes a connection from the patient device PR to the implantable device IMP).

[0069] In another example, the patient device PR may replicate the information to the backend system BE by a replication process similar or identical to the replication process from the user device CP to the backend system BE as outlined for the first case (e.g. a Couchbase Lite to Sync Gateway replication process if the storage medium is a Couchbase server).

[0070] In an example, the entering of the information to the data system 100 may concurrently be accompanied by associating the patient device PR to the implantable device IMP (e.g. during a complete new patient registration, or a re-registration of the implant and the patient device PR in the data system 100). This may be necessary, if the patient device PR has not yet been associated with a (particular) implantable device IMP. Notably, the association process may not necessarily occur during a new patient registration but may also occur at other events (e.g. when the patient device PR initially connects to the implantable device IMP and/or every time the information is entered into the data system, etc.). Subsequently, the association process between the patient device PR and the implantable device is outlined.

[0071] To enable said association, the patient device PR may create a channel-access-request signal (e.g. which may be implemented by or comprise a database entity, a document, a computer instruction, etc.). The channel-access-request-signal may be subsequently replicated to the backend system BE for associating the patient device PR with the implantable device IMP. Further, the patient device PR may be associated with the (entered) information (e.g. information entities) through the association process which may be necessary to associate the patient device PR with the patient having the implantable device IMP.

[0072] In the first case (as outlined herein) the (entered) information (e.g. from a new patient registration) may have been already replicated to the backend system from the user device CP over the first communication path 110. Hence, the channel-access-request signal may arrive after the (entered) information (e.g. comprising patient information entities) has been stored in the backend system BE. Thus, the channel-access-request signal may be processed immediately such that the backend system BE may immediately create an association between the patient device PR sending the request (via the channel-access-request signal) and the patient.

[0073] In the second case (as outlined herein) or when the user device CP is offline, the (entered) information (e.g. from a new patient registration) may not have been transmitted yet to the backend system BE. Hence, the channel-access-request signal may be stored in the backend system BE until the information (e.g. comprising patient information entities) arrives. For example, the information may arrive when the user device CP can get online later to establish a connection to the backend system. Also, it is possible that the information may arrive later from the implantable device IMP over the second communication path (via the patient device), as discussed for the second case.

[0074] In an example, the channel-access-request signal may be triggered when the patient device PR first establishes a Bluetooth pairing with a new implantable device IMP. Subsequently, the according association process is outlined in more detail:

[0075] After provisioning, the patient device PR may not yet be associated with the (entered) information (e.g. a patient). Therefore, to associate itself with a patient, the patient device PR may need to get authorized for accessing patient data in the storage medium (e.g. a database of the distributed database) comprised in the backend system BE (e.g. access to a specific server channel of a data server may be necessary, e.g. a Couchbase channel). Initially, after provisioning, the patient device PR may create an association with the implantable device IMP through a short-distance wireless connection and create the according channel-access-request signal comprising said association information. Subsequently, the patient device PR may transmit (e.g. insert) the channel-access-request signal (e.g. implemented by a channel-access-request database entity) (in)to the storage medium comprised in the backend system BE. The channel-access-request signal may specify information entities that are not patient specific (e.g. patient non-identifiable information, implantable device information, and/or further patient device entities). Subsequently, the patient device PR may push the channel-access-request signal to a synchronization interface comprised in the backend system. For security purposes, information entity references in a channel-access-request signal may not be guessable (e.g. knowing a document identification of one patient, non-identifiable information entity may not allow an attacker to guess another document identification). The backend system BE (or its service center SC) may detect or process the channel-access-request signal which may trigger updating the authorizations for the account of the patient device PR. This may thus enable the authorized patient device PR to access/read patient specific data stored in the backend system. In an example, the authorization may comprise granting read access rights to certain database channels (e.g. Couchbase channels). The patient device PR may wait until the channel-access-request signal is processed. Subsequently, patient device PR may push patient-specific objects to the synchronization interface and/or may access patient-specific objects in the backend system via the synchronization interface.

[0076] To illustrate an example of the communication flow in the data system, a data flow of the (entered) information entities (e.g. patient entities) may start at the user device CP, wherein subsequently the information entities are communicated to the implantable device IMP. Consecutively, the information entities may be communicated to the backend system via the patient device PR. During the message parsing (e.g. of the HM message) the intermediate results (of the parsing process) may be written to the backend system (e.g. to a database server, e.g. a Couchbase server). The results of the further message processing may be subsequently stored in the backend system (e.g. in a database server, e.g. a Couchbase server).

[0077] FIGS. 2a-b show a schematic representation of an exemplary embodiment of a user interface of the user device CP in the data system 100 for entering information associated with the implantable device IMP. As seen in FIG. 2 the user device CP may provide a patient registration general user interface (a patient registration GUI) that allows the user to enter (e.g. register) a new patient (or enter new information associated with the implantable device IMP) in the data system 100 and/or update existing information associated with the implantable device IMP in the data system 100. In the patient registration GUI, the user may enter the information (e.g. patient information) into various fields (e.g. manufacturer patient ID, clinic patient ID, first name, last name, date of birth, information regarding health status, etc.) and may assign the patient to a group, a clinic and/or a clinician. Hence, during this creation process the patient may be initially assigned to the group (or the group may be updated). The assignment of the patient to a group, a clinic and/or a clinician may control access to the information by various users (e.g. a clinician may only have access to patients in specific groups they are assigned to or have access to by a (global) setting). The clinician access may be controlled by the administrative team in a separate process not described here (e.g. to set the (global) setting of the clinician access). When the patient registration GUI is filled out, the information (e.g. a patient entity, a patient identifiable information, a patient non-identifiable information) may be created as a database entity and related to other entities in the database (e.g. the patient entity may be related to the patient group that the patient is assigned to). Additional data created for that patient may be created as information entities in the database (e.g. a follow up information) by the user device CP, the patient device PR, and/or the backend system (e.g. by the service center SC) and related to that patient. This may give the user device CP, the patient device PR, the service center SC access to information about the patient. The patient entity and/or the associated entities may be replicated from the user device CP database to the backend system BE database, as outlined herein. Also, the patient registration GUI may display details of the IMP, such as its serial number.

[0078] As can be seen in FIG. 2a the patient registration GUI may comprise a check box for enabling remote services (e.g. as indicated by “Please check this box to enable remote services”). The check box may allow a user to activate or deactivate a remote monitoring service for the implantable device IMP (and thus the corresponding patient). The remote monitoring service may comprise various remote processes wherein the implantable device IMP and its data and/or settings are remotely accessed/adapted (e.g. during a remote follow-up session, a readout of relevant medical data, an adjustment of therapy settings, a technical check-up, etc.). For example, remote patient monitoring may be understood as a monitoring of a patient outside of conventional clinical settings (e.g. monitoring of a patient in his/her home, in a remote area, during his daily activities, etc.). The remote access to the implantable device IMP may be implemented by any remote (e.g. physically distant) node of the data system. In an example, the remote access may be requested by the backend system BE wherein the remote monitoring service may comprise various communication exchanges between the implantable device IMP and the backend system BE. The communication for the remote monitoring service may be implemented via the patient device PR (which may function as a relay transceiver to further nodes of the data system 100, and for example to the backend system BE).

[0079] FIG. 3 shows a schematic representation of an exemplary embodiment of a user interface of the user device CP in the data system 100 showing a patient assignment form. For example, after the user has registered a patient as discussed in FIGS. 2a-b over the user device CP, the user may manually trigger the transfer of the (entered) information to the implantable device IMP over the initial communication link. The patient assignment form may comprise a display of various patient data (e.g. patient name, date of birth, last device date of implant, etc.) which may give an overview of the (entered) information. Further, the patient assignment format may comprise a prompt to indicate to the user if he wants to proceed and write the (entered) information to the implantable device IMP by transmitting said information via the initial communication link. The user may manually activate a button (e.g. a proceed button) which may trigger the transmitting of the (entered) information to the implantable device IMP for storing the (entered) information redundantly at the two origin nodes (as outlined herein). However, the user may also cancel the transfer of the (entered) information to the implantable device (e.g. if the entered information is false and needs to be reentered).

[0080] FIGS. 4a-b show schematic representations of an exemplary embodiment of a user interface of the user device CP in the data system 100 showing a patient assignment search form. For example, the user device CP may be configured to access a general database which may comprise a record of the information associated with the implantable device IMP for a plurality of patients. The general database may be comprised in the user device CP and/or the backend system BE. For example, the data system 100 may be configured such that it may manage the information associated with a plurality of implantable devices. For example, the data system 100 may be configured to comprise a plurality of implantable devices (e.g. a plurality of patients having the implant), a plurality of patient devices, and/or a plurality of user devices (e.g. to account for multiple clinicians, hospitals, etc.). To that regard, the backend system BE may function as the main node where the information associated with each implantable device may respectively be replicated to. It may also be conceivable that the user device may store each (entered) information which was transmitted to a specific implantable device (as outlined herein) in a general database of the user device. For example, a clinician may register ten patients a day via the user device CP which in turn may lead to ten patient records (with the respective information) in the general database of the user device CP. As seen in FIG. 4a, the user operating the user device may thus search for a specific patient in the general database (e.g. via name, date of birth, or any other information associated with the implantable device, etc.). The patient assignment form may initially display the patients in alphabetical order by the name of the patients. In addition, the assignment search form may display the most relevant information associated with the implantable device (e.g. patient name, manufacturer ID, implantable device serial number (e.g. stimulator serial number), clinician, etc.). As indicated in FIG. 4b when the user may start to enter a patient name, or a set of letters the corresponding search results (of corresponding patients) may be immediately displayed. For example, when the user may search for the last name “Smith”, the according patient (or patients) may be displayed for each subset of letters inputted to the search interface (e.g. when only “Smi” is entered, the search result may immediately display every patient whose last name may start with the set of letters “Smi”).

[0081] In conclusion, the invention may facilitate a variety of benefits. For example, it may enable reducing data entry points of the data system 100 to a minimum and/or it may enable an automatic data sharing between all connected data consumers (i.e. nodes of the data system). Further, it may enable implementing a data update schema that ensures that the revision of the document that is stored in the implantable device IMP (e.g. an implant and/or trial device) will always be higher or equal to the revision of the same document stored elsewhere in the data system 100. Moreover, this may be accomplished with a minimum latency and/or with state-of-the art cybersecurity. In addition, the invention may automatically accommodate for a number of clinical workflows (e.g. a registration can be initiated with or without network connection to the CP).

[0082] Further advantages may be an increased clinician satisfaction via increased ease of registration and ongoing use, patient compliance and registration process reliability; an increased patient satisfaction via increased ease of set-up and use; an increased system performance via higher registration compliance.

[0083] It will be apparent to those skilled in the art that numerous modifications and variations of the described examples and embodiments are possible in light of the above teaching. The disclosed examples and embodiments are presented for purposes of illustration only. Other alternate embodiments may include some or all the features disclosed herein. Therefore, it is the intent to cover all such modifications and alternate embodiments as may come within the true scope of this invention.