Identification method, device, system and corresponding program

Abstract

The invention relates to methods for processing patient data in a healthcare facility using electronic devices and includes steps for obtaining data representing the patient's identity and a wristband identifier, cryptographically associating this data, and storing it in an authentication database. During patient movement, the method authenticates the patient's identity and the wristband identification data by transmitting a visual verification signal upon successful authentication. Fig. 1

Description

Title of the invention: Identification method, device, system and corresponding program

[0001] 1. Domain

[0002] The invention relates to the field of identification. More particularly, the invention relates to the field of patient identification within healthcare facilities. The invention aims more specifically to guarantee the identification of a patient within a healthcare facility simultaneously with their registration within the facility.

[0003] 2. Prior art

[0004] In recent years, healthcare facilities have been the target of much criticism, particularly regarding their management of patient data. Many facilities worldwide have been the victims of targeted attacks aimed at paralyzing their services or obtaining patient data, which is then resold on the black market. These attacks and the resulting problems have been widely documented and are well-documented. However, healthcare facilities also face numerous challenges in patient management, challenges that also involve many security issues. For example, many facilities deal with patient fraud. To some extent, fraud problems also originate within the healthcare facilities themselves.The fraud attributed to patients essentially stems from an uninsured patient using a healthcare appointment slot instead of an insured patient, whose place they have taken, whether with or without the latter's complicity. More specifically, someone arrives at the facility accompanied by a legitimate insured patient and takes their place during the consultation or treatment. This situation is problematic for the healthcare facility for several reasons: the first and most important reason concerns the facility's liability for the care it provides.Indeed, if the person posing as the legitimate patient has a medical history unknown to the healthcare facility, and the treatment provided is inconsistent with that history, a series of adverse health events can occur, potentially leading to the fraudster's death. This could happen, for example, if an antibiotic is prescribed and the fraudster is allergic to it. In some cases, depending on applicable legislation, the healthcare facility may even be held liable and face penalties. The second problem stems from the mixing of the legitimate patient's health data with that of the fraudster. Again, this situation can lead to misdiagnosis for the legitimate insured individual upon admission to the healthcare facility, potentially resulting in their death and the facility being held liable. The third problem is less significant, as it concerns the financial allocation of care to a legitimate insured individual (and to the healthcare facility) when that care should not have been provided; this situation could also lead to the facility being held liable.

[0005] To address this issue, an increasing number of healthcare facilities are requiring, upon patient registration (i.e., upon arrival at a registration desk), identification to verify the prospective patient's identity. When the registration clerk deems this identification valid, the patient registration process continues. This technique is relatively unreliable, as it relies primarily on the facial recognition skills of a single individual (namely, the registration clerk) and does not prevent the fraudster from being substituted for the legitimate insured person once registration is complete (i.e., for example, in the waiting room).

[0006] The invention improves the situation.

[0007] 3. Summary

[0008] Thus, the invention aims to improve patient care within healthcare facilities by preserving the freedom of legitimate patients and limiting the possibilities of fraud potentially leading to medical errors. To this end, the invention describes a method for registering patients.

[0009] More specifically, a data processing method is described, the method being implemented upon the arrival of a patient at a healthcare facility, the method being at least partially implemented through at least one electronic device comprising a processor and memory, the method comprising at least the following steps:

[0010] - obtaining data representative of a patient's identity, said data re patient identity information is encoded according to a predetermined initial encoding format;

[0011] - obtaining data representative of a bracelet identifier to be associated with patient, the said representative data being encoded according to a second predetermined encoding format;

[0012] - cryptographic association of the data representing the patient's identity and of the representative data of the identifier of a bracelet to be associated with the patient;

[0013] - recording the result of said cryptographic association within a database authentication data.

[0014] According to a particular feature, the step of obtaining the data representing the identity of a patient includes:

[0015] - the recording, by a recording terminal, of the patient's arrival within of the healthcare facility, including obtaining, from a patient identification device, data representative of the patient's identity;

[0016] - the standardized encoding of the data representing the patient's identity according to the first encoding format;

[0017] - the transmission of the data representing the patient's identity encoded to a authentication server connected to the registration terminal via a communication network.

[0018] According to a particular feature, the step of obtaining the representative data of the bracelet identifier to be associated with the patient includes:

[0019] - the selection, from a set of bracelets, of the bracelet to be associated with the patient;

[0020] - the transmission of a request to provide an identifier, by a terminal recording, using a near field communication interface, to the bracelet to be associated with the patient;

[0021] - the standardized encoding of the data representing the identifier of a bracelet to be associated with the patient according to the second encoding format;

[0022] - the transmission of the data representing the identifier of a bracelet to be associated to the patient encoded to an authentication server connected to the recording terminal via a communication network.

[0023] According to a particular feature, the cryptographic association step of the data representing the patient's identity and the data representing the identifier of a bracelet to be associated with the patient comprises:

[0024] - the determination of cryptographic material to be used for the data represented sensitive to the patient's identity and / or to the representative data of the identifier of a bracelet to be associated with the patient;

[0025] - the implementation of cryptographic material on the representative data of the patient's identity and / or the representative data of the identifier of a bracelet to be associated with the patient providing encrypted identification data.

[0026] According to a particular feature, the cryptographic association step of the data representing the patient's identity and the data representing the identifier of a bracelet to be associated with the patient further comprises:

[0027] - The transmission of the encrypted identification data to the bracelet assigned to the patient

[0028] - The recording of the encrypted identification data within the assigned bracelet to the patient.

[0029] According to another aspect, the invention also relates to a data processing method, the method being implemented during a patient's journey within a healthcare facility, said patient being equipped with a bracelet associating at least one piece of data representing the patient's identity and one piece of data representing the bracelet identifier (different or identical to that described above), the method being at least partially implemented by means of at least one electronic device comprising a processor and a memory, the method comprising at least the following steps:

[0030] - Obtaining, by a processing device, the data representing the identity of the patient and / or representative data of the bracelet identifier;

[0031] - The authentication of the data representing the patient's identity and / or the representative data of the bracelet identifier; and

[0032] - When the authentication of the data representing the patient's identity and / or The representative data of the bracelet identifier delivers a positive result, a transmission step, to a viewing device, of a signal for visual verification of the patient's identity.

[0033] According to a particular feature, this method further comprises, after the transmission of the visual verification signal of the patient's identity, and when confirmation of the patient's identity is received, at least one recording step, within a database, of at least one association between the patient and at least one data point representative of a medical procedure performed on said patient.

[0034] According to a particular feature, the authentication of the data representing the patient's identity and / or the data representing the bracelet identifier includes at least one step of verification, by an authentication server, of a validity period of the association between the data representing the patient's identity and the data representing the bracelet identifier.

[0035] According to another aspect, the invention also relates to a system for implementing a process as previously described.

[0036] According to another aspect, the invention also relates to computer programs capable of implementing the described process(es) and to a data carrier for recording these computer programs.

[0037] The devices have the architecture of a computer. They are equipped with one or more processors capable of executing all types of computer programs, from operating systems to application software, written in compiled or interpreted languages. The various components of the device are interconnected by a communication bus. The device is equipped with a communication system The device is designed to communicate with other systems via protocols such as Bluetooth, Ethernet, or Wi-Fi, and to connect to mobile or fixed telecommunications networks. It also includes memory components that store the data and programs necessary for its operation. Furthermore, the device is modified to perform management operations on a large number of vehicles and handle several thousand simultaneous operations per second, notably through the parallel execution of route calculations.

[0038] Data carriers can be any entity or device capable of storing programs. For example, the carriers can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means such as a hard drive, or more commonly, flash memory. Alternatively, the carriers can be transmissible media such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The programs according to the invention can, in particular, be downloaded from a network such as the Internet. Alternatively, the information carrier can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0039] 4. Drawings

[0040] Other features and advantages of the invention will become more apparent upon reading the following description of a particular embodiment, given by way of simple illustrative and non-limiting example, and the accompanying drawings, among which:

[0041] - [Fig.1] illustrates a system for implementing the processes of the invention;

[0042] - [Fig.2] represents the main steps of the patient registration process;

[0043] - [Fig.3] represents the main steps of the patient authentication process.

[0044] 5. Description of an embodiment

[0045] An architecture of a system in which the patient registration process and the patient authentication process can be implemented is presented in relation to [Fig. 1]. In this SYST system, an authentication server ServA is connected to an NTWK communication network of the healthcare facility. The communication network can be a wired network, a wireless network (such as Wi-Fi), or a combination of these network types. At least one registration terminal TermE is also connected to the NTWK communication network. The registration terminal is used to register patients entering the healthcare facility to receive care, implementing the patient registration process according to this disclosure. The SYST system also includes at least one transaction server ServT. The transaction server is also connected to the NTWK communication network. It is usedconcurrently with the authentication server, particularly for consolidation operations, as described below. The SYST system also includes at least one Brld identification bracelet. The identification bracelet includes at least data processing capabilities and near-field communication capabilities such as RFID or NFC. The Brld identification bracelet is provided to the patient during the patient registration process. The SYST system also includes at least one DiTr treatment device. The treatment device is made available to the practitioner. Depending on the configuration, a DiTr treatment device may be shared among several practitioners, or each practitioner may have their own treatment device, or a combination of these two scenarios.The processing device is equipped with data processing capabilities as well as means for interacting with the Brld identification bracelet, primarily including an NFC reader and / or an RFID reader, and optionally image capture capabilities. The SYST system optionally includes MDetc detection capabilities for the Brld identification bracelet. These MDetc detection capabilities can take the form of bracelet reading terminals, connected to the NTWK communication network, which transmit data from queries to various near-field devices located in one or more specific areas of the healthcare facility, depending on the configuration. The data obtained by these terminals is transmitted to a ServD detection server, which is also connected to an NTWK communication network.Depending on the implementation, the transactional server ServT, the authentication server ServA, and the optional detection server ServD can be a single server, virtualized, or a combination of these architectures.

[0046] In relation to [Fig. 2], a patient registration method conforming to the disclosure is described. Such a method is primarily implemented by the authentication server ServA, the registration terminal TermE, and a Brld identification bracelet assigned to a patient. The purpose of the registration method is to associate the identity of a patient entering the healthcare facility with the Brld identification bracelet, within a framework of healthcare facility security, patient care security, and fraud detection / prevention, whether intentional or resulting from negligence.

[0047] The main steps of this process include obtaining the patient and bracelet data (obtaining data representing the patient's identity encoded according to a first predefined format, obtaining data representing the identifier of a bracelet to be associated with the patient, encoded according to a second predefined format, cryptographically associating the patient and bracelet data, the registration of this association in an authentication database). Among these steps: the registration of the patient's identity includes: the registration of the patient's arrival via a terminal, obtaining the patient's data, the standardized encoding of the patient's data and transmission to the authentication server; Obtaining the bracelet identifier includes: selecting the bracelet to be associated with the patient from a selection, transmitting an identifier request to the bracelet via a terminal, standardized encoding of the bracelet identifier, and transmission to the authentication server. Cryptographic association includes: determining the cryptographic material to be used; encrypting the patient and / or bracelet data to obtain encrypted identification data. Transmission and recording include transmitting the encrypted data to the bracelet assigned to the patient and recording the encrypted data in the bracelet assigned to the patient. This process aims to secure the identification of patients and their associated bracelets upon admission to a healthcare facility, using cryptographic techniques to guarantee data integrity and confidentiality.The first and second predetermined encoding formats ensure the uniqueness of the association data stored within the authentication system. This may involve, more specifically, a base64 encoding (for the bracelet identifier) ​​or a Unicode encoding for patient identification. In the following sections, we assume that we are working with data encoded according to one or more predefined formats that guarantee data uniqueness.

[0048] Thus, the method comprises, in one embodiment, the following steps:

[0049] - the recording E01, by the recording terminal TermE, of the arrival of the patient within the healthcare facility, this record providing data representative of the patient's identity DPat;

[0050] - the transmission E02 of the data representing the patient's identity DPat, by the TermE registration terminal, to the ServA authentication server;

[0051] - the E03 transmission of an IdB bracelet identifier by the terminal TermE registration, to the ServA authentication server; the bracelet whose identifier is transmitted corresponds to the bracelet selected by the patient registration attendant; the bracelet can be taken at random by the attendant, from a receptacle provided for this purpose, then placed on an NFC type reading / recording device connected to the TermE registration terminal and the Brld identification bracelet transmits its IdB bracelet identifier to the TermE registration terminal, which then transmits this identifier to the ServA authentication server.

[0052] The two transmission steps may be simultaneous or constitute a single transmission step.

[0053] - The reception E04, from the ServA authentication server, of a key temporary access TaK, encrypted using the public key of the Brld identification bracelet;

[0054] - The transmission E05, to the Brld identification bracelet, of the temporary access key TaK encrypted;

[0055] - The decryption E06, by the Brld identification bracelet, of the access key temporary TaK encrypted, using its private key, followed by the E07 record of this decrypted temporary access key and the data representing the patient's identity DPat.

[0056] This method ensures that the bracelet is cryptographically linked to a single patient identity. In addition to, or instead of, the E07 registration step, the Brld identification bracelet can implement an encryption step for the patient identity data DPat using the temporary access key TaK to provide even greater security. In this case, neither the temporary access key nor the patient identity data DPat is stored, and only the patient identity data DPat using the temporary access key TaK is recorded on the bracelet. Alternatively, the encryption step for the patient identity data DPat using the temporary access key TaK can be implemented by the ServA authentication server.In which case, the authentication bracelet doesn't even need to perform this encryption and simply decrypts the data received from the server using its private key.

[0057] Depending on the operational implementation conditions, the E01 recording, by the TermE recording terminal, of the patient's arrival at the healthcare facility may include several characteristics.

[0058] In one embodiment, this registration is carried out using the patient's social security card. More specifically, the TermE registration terminal is equipped with a reader for such a social security card (which is, for example, a smart card, as in France, Germany, or the United States, or a digital card on a smartphone). The following registration process is then implemented: the TermE registration terminal transmits a request to the social security card to obtain identification data, which may include the patient's surname, first name, date and place of birth, social security number, and photograph.

[0059] Equipped with all or part of this data, the TermE recording terminal can transmit it as is to the ServA authentication server during transmission step E02. It can also preprocess it to derive a synthetic data point representing the patient's identity. This preprocessing can consist of concatenating the data received from the card into a string of characters, encoding the data, for example in base 64, giving a The encoded string is then processed using a signature algorithm (SHA-3). The resulting data then constitutes the representative data for the patient's identity (DPat). This preprocessing can also be performed by the ServA authentication server.According to the disclosure, the process also includes obtaining a photo of the patient by the ServA authentication server: this photo is provided by the social security card and the TermE registration terminal, or a photograph is taken on the patient's arrival by the TermE registration terminal during the collection of information about him, or a photograph is retrieved from the ServT processing server (from a previous visit of the patient within the health establishment) or the ServA authentication server already has, in the database, a photograph associated with the data representing the identity of the patient DPat already in the possession of the ServA authentication server.As an alternative to, or in addition to, the use of a social security card, all or part of the aforementioned data may be entered into a patient registration application at the TermE registration terminal.

[0060] Upon receipt of these elements, the ServA authentication server is able to determine a temporary access key for the patient. Cleverly, the temporary access key is determined randomly or pseudo-randomly and includes, for example: obtaining random or pseudo-random data, in the form of a string of characters (for example, encoded in base 64), determining a time limit for the use of the bracelet (date / time) [for example, linked to the care that the patient is receiving at the healthcare facility, in particular, for example, in relation to a scheduled appointment time, as well as a maximum duration associated with this appointment].This data (random string and time / date of care) is, for example, concatenated with the patient's identity data (DPat) or with data derived from the patient's identity data (DPat) (for example, data resulting from the encryption, by the authentication server, using its private key, of the patient's identity data (DPat). The resulting concatenated string is then encoded and, for example, hashed using a suitable algorithm (SHA-3). This encoded and hashed string then constitutes the temporary access key. This temporary access key, its expiry date, and the patient's identity data are then stored in the authentication server's database for later verification, as described below.

[0061] Depending on the operational implementation conditions, the E01 registration, by the TermE registration terminal, of the patient's arrival can be simplified, for example by transmitting the patient identity data DPat and the bracelet identifier IdB to the ServA authentication server; and entrusting the ServA authentication server with the function of securing the link between these two pieces of information, without necessarily transmitting data to the bracelet, although this procedure is suboptimal.

[0062] In an alternative, the bracelet whose identifier is transmitted corresponds to that of a bracelet pre-selected by the recording device from among a set of available bracelets; in which case, at least some of the bracelets have warning means (such as an apparent LED, for example, but also autonomous data transmission means, i.e. not receiving energy from an NFC or RFID antenna) allowing the bracelet to be signaled / recognized from among the set of available bracelets.

[0063] As explained previously, one object of the invention is to enable the healthcare facility to verify that the person presenting themselves for treatment is indeed who they claim to be. The objective is to ensure, firstly, that the healthcare facility provides care that is appropriate for the patient and, secondly, that the patient is indeed who they claim to be.

[0064] This data processing method is used during a patient's visit to the healthcare facility, where the patient wears a bracelet containing identity and identifier data. Implemented by electronic devices, it involves obtaining the patient and bracelet data, authenticating them, and, if successful, transmitting a visual identity verification signal to a display device. This process aims to ensure secure and reliable patient identification throughout their medical stay, thereby strengthening care management and patient safety. Other secondary objectives are also pursued, as explained below. In this context, once the patient arrives in the treatment or examination room, a patient authentication process is implemented. This process is three-part. It allows for the fulfillment of the two objectives mentioned above.More specifically, the process includes, in an example implementation, the following steps: .

[0065] - the transmission V01, by the processing device DiTr, of a request for obtaining of the data representing the patient's identity (recorded within the patient's bracelet); optionally (and / or alternatively) the retrieval request includes the data representing the identifier of the DiTr treatment device;

[0066] - the transmission V02, via the patient's bracelet, of a response containing the data representing the patient's identity encrypted using the temporary access key TaK; and optionally (and / or alternatively) containing the practitioner's terminal identifier encrypted using the temporary access key TaK;

[0067] - Upon receipt of this response, the V03 transmission, via the processing device DiTr, to the authentication server (SrvA), of an authentication confirmation request, including on the one hand the response provided by the patient's bracelet and on the other hand a data representative of the identifier of the DiTr treatment device (optionally (and / or alternatively) encrypted using the private key of the DiTr treatment device);

[0068] - the V04 verification, by the authentication server (SrvA), of the validity of the data transmitted, including:

[0069] - if it is encrypted by the private key of the DiTr processing device, the decryption of the patient's bracelet identifier (IdB) using the DiTr treatment device public key held by the authentication server (SrvA);

[0070] - obtaining the temporary access key (TaK), using the bracelet identifier (IdB) of the patient;

[0071] - deciphering the response provided by the patient's bracelet using the key temporary access key (TaK) of the authentication server (SrvA), when this temporary access key is obtained (i.e., decryption of the data representing the patient's identity; and optionally (and / or alternatively) the retrieval request includes the data representing the DiTr treatment device identifier);

[0072] - the comparison of the data representing the deciphered patient identity with that corresponding to the temporary access key TaK associated with the device and the patient

[0073] - optionally, the comparison of the representative data of the identifier of the DiTr treatment device (provided by the patient's bracelet response) with that provided by the DiTr treatment device itself (this feature helps prevent "fraudulent" alteration of the patient's bracelet; and

[0074] - when the verification operations performed by the authentication server deliver a positive result, a transmission step, to the DiTr treatment device, of the data representing the patient's identity (optionally (and / or alternatively), this data is transmitted encrypted with the public key of the DiTr treatment device) (optionally (and / or alternatively), the NULL value can be transmitted to the DiTr treatment device, when the verification operations fail);

[0075] - the reception V05, by the DiTr processing device, of the response from from the authentication server, this response including at least, if valid, the data representing the patient's identity;

[0076] - obtaining V06, by the DiTr processing device, a visual data (HRd) usable by the practitioner and associated with data representing the patient's identity, this visual data allows confirmation of the patient's identity (it may be, for example, example of a photograph, or a copy of an official document: copy of insurance card, copy of identity document).

[0077] Depending on the operational implementation conditions, the patient's bracelet may simply transmit its identifier. In this case, the authentication server performs a patient identity verification using the link between the bracelet's identifier and data representing the patient's identity, although this procedure is suboptimal. The practitioner can then receive, on the DiTr processing device, the visual data (HRd) usable by the practitioner and associated with the data representing the patient's identity.

[0078] Optionally (and / or alternatively), in response to the request to obtain the patient's identity data, the bracelet can also transmit (and encrypt) the bracelet identifier (BID), either as data directly from its memory or indirectly, as explained below. This bracelet identifier can then be compared to a bracelet identifier expected by the authentication server, either in addition to or instead of the patient's identity data. In which case, the authentication process steps described above are modified or added accordingly.

[0079] Obtaining the temporary access key (TaK), using the patient's bracelet identifier (IdB), includes:

[0080] - a step of obtaining, within a data structure, the last access key temporary attributable to the patient's bracelet based on the identifier;

[0081] - a step to verify the validity of the last temporary access key, particularly depending on a deadline for using this last temporary access key; and

[0082] - when the use-by date / time is later than the current date / time, a step of providing the last temporary access key, which constitutes the temporary access key (TaK);

[0083] - when the cut-off date / time is earlier than the current date / time, a A NULL value is provided in place of the temporary access key (TaK).

[0084] Thus, if a patient bracelet is presented outside of predefined time slots, decryption of the data transmitted by this patient bracelet by the authentication server is not possible, since no temporal data can be associated with this patient bracelet. Therefore, when scanning the bracelet of a patient presenting for care, the practitioner is informed of the impossibility of identifying the patient, either via a generic message displayed on the practitioner's terminal, or via a specific message indicating the reason for this inability to identify the patient. Optionally (and / or alternatively), the practitioner has the possibility of overriding this identification, for example, if the practitioner is (well) aware the patient in question and that he is able to ensure (manually) that the patient is indeed who he claims to be.

[0085] When authentication is successfully completed (after scanning the patient's wristband), the DiTr treatment device is ready to associate the treatment data (entered or selected) by the practitioner with the correctly identified patient's record. This association can be performed by selecting, from a set of procedures that can be associated with the patient, the procedures that the practitioner performs. Optionally (and / or alternatively), the data relating to the procedures that can be associated with the patient are extracted from a database of possible procedures. This database of possible procedures is, for example, filtered according to data representative of the patient (e.g., the pathology(ies) associated with the patient) so as to retain only the procedures that can actually be performed.The advantage of this methodology is that it is easy for a practitioner to ensure that the actions they perform are indeed related to the patient's state of health. This methodology also significantly reduces the risk of medical errors: indeed, by assuring that the patient consulting them is in fact who they claim to be (or expect to be), the practitioner performs the correct actions and is protected from liability in the event of patient fraud (that is, if, despite all the safeguards in place, the patient still manages to confuse or defraud the system).

[0086] Thus, for example, using the patient's identifier and a practitioner's identifier, a human-machine interface is implemented to identify, within a database, the procedures attributable to the patient, that is, the procedures which, given the reason or reasons why the patient is present at the healthcare facility, are performed by the practitioner. The DiTr processing device sends a request to at least one transactional server which, in response, transmits the procedure data attributable to the patient. The practitioner selects the procedures in question, and the DiTr processing device creates a data record in which the patient's identifier is inserted, as well as the practitioner's identifier and the identifier of the procedure performed. For example, a record of the following type is created and inserted into a database of procedures performed:

[0087] Id ;patient_id ;csarr_id;user_id;intervenor_id;observation;acte_duree_id;weighting;processed_at;c reated_at;updated_at

[0088] Cryptographic data can also be calculated based on all the data in the record; this cryptographic data can, for example, take the form of a hash of all or part of the (concatened) data in the record. This hash is, for example, added as a field in the record, or inserted into another database table, in order to Securing the record's content and tracking any modifications to it is always a security measure: if one or more data points in the record (excluding observations) are subsequently modified, the hash of these data will differ from the initial hash, making fraud or attempted fraud easier to detect. Furthermore, this hash can also be inserted as a transaction into a private blockchain, for example, one held by the healthcare facility or a trusted third party, allowing for the tracking of various actions related to the patient. In this context, the allocation of the bracelet to the patient during registration, and therefore the creation of the associated cryptographic data, can also be hashed, and this hash can also be inserted into a database table and / or the blockchain described above.

[0089] Optionally (and / or alternatively), the patient authentication process can be supplemented by obtaining, from the DiTr processing device, data printed on the patient's wristband, in particular from a QR code printed on the outer surface of the patient's wristband. This QR code contains information (the wristband identifier (IdB)) which is encrypted using the wristband's public key. This encrypted identifier can only be correctly decrypted by the processor within the wristband. Therefore, the DiTr processing device is able to scan the QR code and decode the information it contains (the identifier encrypted with a public key).After decoding, the encrypted identifier obtained from this QR code is transmitted to the patient's wristband (for example, when requesting the patient's identity data). The patient's wristband then uses its private key to decrypt this data. If successful, this decryption yields the wristband identifier (IdB). If unsuccessful, the value is different from the patient's wristband identifier (IdB). Regardless of the outcome, the obtained data (i.e., if successful, the wristband identifier (IdB) issued to the patient) is injected into the authentication process described previously and transmitted (alone or in combination with the patient's identity data, as explained above).If the data does not match the patient's bracelet identifier (IdB), the authentication process will fail, and it may be concluded that the bracelet is counterfeit, does not belong to the healthcare facility, or that the patient is not who they claim to be. In any case, a corresponding alert is triggered in the DiTr processing system, and the practitioner can review this alert to take the necessary action.

[0090] Another advantage of the proposed technology is that the patient can potentially return home while keeping the bracelet given to them upon registration at the healthcare facility and return to the facility with this same bracelet to receive other treatments.

Claims

Demands

1. A data processing method, the method being implemented upon the arrival of a patient at a healthcare facility, the method being implemented via at least one electronic device (TermE, ServA) comprising a processor and memory, the method comprising at least the following steps: - obtaining (E01, E02) data representing a patient's identity (DPat), said data representing the patient's identity being encoded according to a first predetermined encoding format; - obtaining (E03) data representing an identifier (IdB) of a bracelet (Brld) to be associated with the patient, said data representing being encoded according to a second predetermined encoding format; - cryptographic association (E04, E05) of the data representing the patient's identity and the data representing the identifier of a bracelet to be associated with the patient;- recording the result of said cryptographic association within an authentication database.;

2. A data processing method according to claim 1, characterized in that the step of obtaining (E01, E02) the patient identity data (DPat) comprises: - the recording (E01), by a recording terminal (TermE), of the arrival of the patient at the health establishment, including obtaining, from a patient identification device, the patient identity data (DPat); - the standardized encoding of the patient identity data (DPat) according to the first encoding format; - the transmission (E02) of the encoded patient identity data (DPat) to an authentication server (ServA) connected to the recording terminal (TermE) by a communication network.

3. Data processing method according to claim 1, characterized in that the step of obtaining the representative data of the identifier (IdB) of the bracelet (Brld) to be associated with the patient comprises: - the selection, from a set of bracelets, of the bracelet (Brld) to be associated with the patient; - the transmission of a request to provide an identifier, by a recording terminal (TermE), using a near field communication interface, to the bracelet (Brld) to be associated with the patient; - the standardized encoding of the representative data of the identifier of a bracelet to be associated with the patient according to the second encoding format 9 - the transmission of the representative data of the identifier of a bracelet to be associated with the patient encoded to an authentication server (ServA) connected to the registration terminal (TermE) by a communication network.

4. Data processing method according to claim 1, characterized in that the cryptographic association step (E04, E05) of the data representing the patient's identity and the data representing the identifier of a bracelet to be associated with the patient comprises: - the determination of cryptographic material to be used for the data representing the patient's identity and / or the data representing the identifier of a bracelet to be associated with the patient; - the implementation of the cryptographic material on the data representing the patient's identity and / or on the data representing the identifier of a bracelet to be associated with the patient, delivering encrypted identification data.

5. Data processing method according to claim 4, characterized in that the cryptographic association step (E04, E05) of the data representing the patient's identity and the data representing the identifier of a bracelet to be associated with the patient further comprises: - the transmission of the encrypted identification data to the bracelet assigned to the patient; - the recording of the encrypted identification data within the bracelet assigned to the patient.

6. Data processing method, the method being implemented during a patient's journey within a healthcare facility, said patient being equipped with a bracelet (Brld) associating at least one data representing the patient's identity (DPat) and a data representing the bracelet identifier (IdB) according to any one of claims 1 to 5, the method being at least partially implemented through at least one electronic device (DiTr, ServA) comprising a processor and a memory, the method comprising at least the following steps: - obtaining, by a processing device DiTr, the data representing the patient's identity (DPat) and / or the data representing the bracelet identifier (IdB); - authentication of the patient identity representative data (DPat) and / or the bracelet identifier representative data (IdB); and - when the authentication of the patient identity representative data (DPat) and / or the bracelet identifier representative data (IdB) delivers a positive result, a transmission step, to a viewing device, of a visual verification signal of the patient's identity.

7. Data processing method according to claim 6, characterized in that it further comprises, after the transmission of the visual verification signal of the patient's identity, and when confirmation of the patient's identity is received, at least one recording step, within a database, of at least one association between the patient and at least one data point representative of a medical procedure performed on said patient.

8. Data processing method according to claim 6, characterized in that the authentication of the patient identity representative data (DPat) and / or the bracelet identifier representative data (IdB) includes at least one verification step, by an authentication server, of a validity period of the association between the patient identity representative data (DPat) and the bracelet identifier representative data (IdB).

9. System for implementing a method according to any one of claims 1 to 8, characterized in that it comprises: - an authentication server (ServA) connected to a communication network (NTWK) of the healthcare establishment; - at least one recording terminal (TermE) is also connected to the communication network (NTWK); - at least one transactional server (ServT) connected to the communication network (NTWK); - at least one identification bracelet (Brld), comprising near-field communication means of the RFID or NFC type; - at least one processing device (DiTr), available to a practitioner comprising an NFC reader and / or an RFID reader.

10. A computer program comprising instructions for implementing a method according to any one of claims 1 to 8, when said instructions are executed by a processor of a computer processing circuit

Images