Abstract:
To overcome the drawback of difficulties when interchanging a patient&#39;s health record among different health information management systems and yet keep the patient&#39;s privacy, this invention proposes a method comprising the steps of: extracting, from a certificate, a signature of a first service provider and a first identifier; generating a second identifier corresponding to the first identifier; sending a request to any one of a second identifier manager and the first service provider so as to request a record associated with the first identifier; receiving the requested record from any one of the second identifier manager and the first service provider; and associating the requested record with the second identifier. Use of the proposed method provides the advantage that there is no need to unify all health information management systems adopting the same pseudonymization service, and makes it easy to share health information among different health information management systems without disclosing the patient&#39;s privacy.

Description:
FIELD OF THE INVENTION 
       [0001]    This invention relates to information interchange systems, particularly to systems and apparatus for interchanging health information among different health information management systems. 
       BACKGROUND OF THE INVENTION 
       [0002]    In recent years, health and/or medical information management systems have been established all over the world. Managing patients&#39; health information and privacy among these health information management systems has become a very important issue. After the Health Insurance Portability and Accountability Act (HIPAA) was enacted by US Congress in 1996, researchers, physicians and medical centers became more careful to deal with the data of patients, including patients&#39; health information and privacy. 
         [0003]    According to ISO, anonymization is the process that removes the association between the identifying data set and the data subject. Pseudonymization is a particular type of anonymization that removes the association between the identifying data set with a data subject and adds an association between a particular set of characteristics relating to the data subject and one or more pseudonyms. Pseudonymization is recognized as an important method of protecting the privacy of patients. ISO/TC 215 is developing a new specification “Pseudonymization practices for the protection of personal health information and health related service” (ISO/DTS 25237), which focuses on principles and requirements using the pseudonymization service for the protection of personal health information. 
         [0004]    Based on ISO/DTS 25237, HITSP (Healthcare Information Technology Standards Panel) developed architecture, illustrated in  FIG. 1 , for implementing pseudonymization. In the architecture  100 , four entities are included, namely the patient, the hospital, the PIX (Patient Identifier Cross-reference) manager and the Pseudonymization service provider. In step  110 , the hospital provides a registration service for the patient. In step  120 , the hospital subsequently sends patient information to the PIX manager. The patient information may only include the patient&#39;s real identifier (patient&#39;s name and ID number) and the patient&#39;s record ID which can be used in this hospital, or it may include more information, such as the address, contact information, etc. In step  130 , the PIX manager records the patient identifier. In this step, the PIX manager also associates the patient identifier with at least one of additional information components contained in the patient information sent from the hospital, such as the patient&#39;s health record ID, address, contact information, etc. In step  140 , the PIX manager sends a request for a pseudo identifier to the pseudonymization service provider. Upon receiving the request, the pseudonymization service provider assigns, in step  150 , a pseudo identifier for the patient and, in step  160 , returns the pseudo identifier to the PIX manager. Then the PIX manager stores and associates the pseudo identifier with the patient&#39;s identifier. Optionally, the PIX manager can also associate the pseudo identifier with the patient information received from the hospital, e.g. the patient&#39;s ID, address and contact information, etc. In step  180 , the PIX manager prepares a pseudo certificate for the patient and sends it to the hospital. In step  190 , the hospital records the certificate and, in step  195 , sends the certificate to the patient. After receiving the certificate, the patient can use this certificate in this hospital and other hospitals understanding the format of this certificate. By using this certificate, the patient can obtain service from the hospitals understanding the format and content of this certificate and avoid disclosing his real identifier. 
         [0005]    However, with the precondition of a unique pseudonymization service available for all the entities in different hospitals, the architecture  100  can only be used in one health/medical information management system/domain, in which all the hospitals can recognize this certificate including pseudo identifiers issued by a common pseudonymization service provider. Currently, people have more and more possibilities to visit different hospitals in different cities, or even different countries. It is unreasonable to assume that different hospitals in different cities and different countries adopt a common pseudonymization service. The patient therefore has to re-register a new identifier or certificate in each health/medical service provider system. Since there is no method of interoperability between different systems, it is difficult for patients to re-use their previous health/medical information stored in different systems. 
         [0006]    Therefore, there is a need to provide methods that are capable of interchanging health/medical information among different health/medical information management systems, which adopt different pseudonymization services. 
       SUMMARY OF THE INVENTION 
       [0007]    It is an object of the invention to provide methods and apparatus for interchanging information, especially health/medical information among different health/medical information management systems, especially those systems using different pseudonymization services. 
         [0008]    According to one embodiment of the invention, the object and several other objects are obtained in a first aspect of the invention by providing an information interchange system. The information interchange system comprises: a reader configured to read a certificate comprising a first identifier and a signature; a reader configured to extract, from a certificate, a signature of a first service provider and a first identifier and generate a second identifier corresponding to the first identifier; a first identifier manager configured to associate the first identifier with the second identifier and send a request to any one of a second identifier manager and the first service provider so as to request a record associated with the first identifier; a receiver configured to receive the requested record from any one of the second identifier manager and the first service provider and associate the received record with the second identifier. 
         [0009]    The record associated with the first identifier includes any one of a medical record, a disease history, and other health/medical information relating to the patient identified by the first identifier, but does not include the patient&#39;s real identifier, such as his identification number, driver license number, insurance number, or medical registration number which can easily reverse the patient&#39;s real identity. 
         [0010]    This system, used for a current health/medical information management system, has the advantage that health information, for example, the record associated with the first identifier, is obtained from another health/medical information management system without the need for the current health/medical information management system to recognize the certificate issued by another system. In the current system, the second identifier can be associated with the patient&#39;s previous record. Records can thus be interchanged among different systems without the need for a unique pseudonymization service. 
         [0011]    Optionally, the second identifier manager further comprises: an identifier mapping unit configured to map the first identifier to a third identifier; a database configured to retrieve a record associated with the third identifier; a sender configured to send the retrieved record to the receiver as being the record associated with the first identifier. 
         [0012]    The third identifier may be the patient&#39;s real identity, such as his identification number, driver license number, insurance number, or medical registration number, so that the record associated with his real identity can be found. The database may be a standalone database or a separate hospital storing a patient&#39;s real identity and record. 
         [0013]    Optionally, the third identifier may also be a pseudo identifier generated by a pseudonymization service provider. The second identifier manager, which may be a PIX manager, can also use this pseudo identifier to retrieve a record from the database. 
         [0014]    Alternatively, when the second identifier manager finds that the third identifier was issued by another health/medical information management system using another pseudonymization service which it does not support but can extract the information about the other pseudonymization service provider, the first identifier can send the third identifier to the other pseudonymization service so as to request a record. By using this recursive method, it is possible to find the initial system that stored the patient&#39;s health record, irrespective of whether the certificate held by the patient was issued by any other health/medical information management system. 
         [0015]    Optionally, the information interchange system further comprises a second service provider configured to generate identifiers, wherein any one of the reader and the first identifier manager is further configured to request a fourth identifier from the second service provider, and the reader is further configured to set the received fourth identifier as the second identifier. Furthermore, the second service provider is further configured to generate a second certificate which can be used by the patient in the current health information management system. The patient can also bring this second certificate to another health information management system, which can obtain a record from the current health information management system by using the above-mentioned methods. 
         [0016]    The first identifier and the second identifier may be pseudo identifiers for identifying a patient without disclosing his real identity. The patient&#39;s privacy is protected in both health information management systems. 
         [0017]    The signature generated by the first service provider provides information about at least one of the second identifier manager and the first service provider, e.g. a pseudonymization service provider. 
         [0018]    According to another embodiment of the present invention, it is a second aspect of the invention to provide a card for storing a certificate configured to identify a patient, wherein the certificate comprises: a first pseudo identifier generated by a pseudonymization service provider and configured to be used in a health information management system; and a signature of a pseudonymization service provider, configured to contain information about at least one of the pseudonymization service provider and an identifier manager, wherein the identifier manager is configured to identify the first pseudo identifier. 
         [0019]    Since the patient&#39;s real identity is not contained in this card, his privacy is protected. In combination with the methods disclosed above, the patient&#39;s record can be found and used in the current health information management system. 
         [0020]    To further enhance the security of the certificate, i.e. to check the link between the certificate and the person holding this certificate, i.e. whether the certificate belongs to this person, the certificate may optionally further comprise a public key of a public key pair. The public key is used to verify the patient&#39;s signature. Since, in this certificate, the public key is associated with the pseudo identifier of the patient, the patient uses the private key of the public key pair to sign some documents, and the other party uses the public key in the above certificate to verify the signature without disclosing the patient&#39;s real identity. The public key can be used online, e.g. through the Internet. 
         [0021]    In another embodiment, an additional dataset may be comprised in the certificate so as to enhance security. The additional dataset may be a hash of a secret s, wherein the s may be a parameter known by the patient, personal information of the patient, or the patient&#39;s real identity. As the hash function is a one-way function for which there is zero-knowledge proof, the patient can prove to the other party, e.g. a doctor, that the certificate with his pseudonym is indeed his, without revealing his identity. 
         [0022]    In another embodiment, an additional dataset may comprise at least one biometrical parameter representing the patient. The biometrical parameter, such as a fingerprint, can be used to verify the patient holding the certificate. It is an additional advantage that the biometrics is always carried by the patient. The biometrics is not stored in a public database and therefore cannot be linked to the patient&#39;s real identity, while it keeps the function of proving ownership of the certificate. 
         [0023]    According to another embodiment, a third aspect of the invention is achieved by providing a method of obtaining information, especially among different health/medical information management systems. The method comprises the steps of:
       a) extracting, from a certificate, a signature of a first service provider and a first identifier;   b) generating a second identifier corresponding to the first identifier;   c) sending a request to any one of a second identifier manager and the first service provider so as to request a record associated with the first identifier;   d) receiving the requested record from any one of the second identifier manager and the first service provider; and   e) associating the requested record with the second identifier.       
 
         [0029]    According to another embodiment, it is a fourth aspect of the invention to provide a method of generating a second certificate, especially without the need of knowing the patient&#39;s real identity. The method comprises the steps of:
       a) extracting, from the first certificate, a signature of a first service provider and a first identifier;   b) checking the validity of the first identifier on the basis of at least one of the signature of the first service provider and the first identifier; and   c) generating the second certificate comprising a second identifier and signature of a second service provider, wherein the second identifier corresponds to the first identifier.       
 
         [0033]    Use of this method provides the advantage that a new certificate comprising a pseudo identifier can be created without knowing the patient&#39;s real identity. 
         [0034]    To enhance security, the second certificate may optionally further comprise any one of a public key, a hash of secret s, biometrical parameters, and other information which can be used to verify ownership of the second certificate. 
         [0035]    Optionally, the method further comprises a step of associating the record associated with the first identifier with the second identifier as being the record associated with the second identifier. 
         [0036]    These and other aspects, features and/or advantages of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0037]    Embodiments of the invention will be described, by way of example only, with reference to the drawings, in which 
           [0038]      FIG. 1  illustrates the architecture developed by HITSP. 
           [0039]      FIG. 2  illustrates a certificate according to one embodiments of the invention. 
           [0040]      FIG. 3  illustrates an information interchange process according to one embodiment of the invention. 
           [0041]      FIG. 4  illustrates a method of generating a certificate according to one embodiment of the invention. 
           [0042]      FIG. 5  is a block diagram of an information interchange system according to one embodiment of the invention. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0043]      FIG. 2  illustrates, by way of example, an embodiment of content of a certificate. The certificate comprises a pseudo identifier and a signature of a pseudonymization service. The pseudo identifier is generated by a pseudonymization service provider and used to identify the patient in a current health/medical information management system, e.g. a hospital in which the patient registers. It is not possible to deduce the patient&#39;s real identity from the pseudo identifier only. The signature of the pseudonymization service is generated by the pseudonymization service provider and can be used to validate the pseudo identifier. The certificate can also be used to deduce the information about the pseudonymization service provider. Optionally, the certificate can be further used to deduce information about an identifier manager, e.g. a PIX manager, in which the patient&#39;s one previous identifier and the association between the previous identifier and the new pseudo identifier generated by the current pseudonymization service provider are stored. The previous identifier may be the patient&#39;s real identity, in which case the hospital is the first registered hospital for the patient. The previous identifier may also be a pseudo identifier generated by another pseudonymization service provider, in which case the current hospital is not the first registered hospital for the patient, and the patient bringing a certificate comprising a pseudo identifier comes to the current hospital. In the latter case, it is possible to use a recursive method to deduce the first registered hospital for the patient. 
         [0044]    In another embodiment, the certificate may optionally comprise a public key of a public key pair. Since, in the certificate, the public key is associated with the patient&#39;s pseudo identifier, the patient can use the private key of the public key pair to sign some document, and another person can use the public key to verify the signature of the patient without disclosing his real identification. It is an advantage to use the public key to verify the patient online, e.g. through the Internet or a dedicated intranet. In this case, the public key is optionally taken into consideration when generating the signature of the pseudonymization service, which further enhances the security of the certificate. 
         [0045]    In another embodiment, the certificate optionally comprises an additional dataset which is used to enhance the security that the certificate belongs to the patient. In this case, the additional dataset is optionally taken into consideration when generating the signature of the pseudonymization service, which further enhances the security of the certificate. It is advantageous that the doctor can ascertain whether he is dealing with the right patient and the right health record. The additional dataset may be a hash of a secret s, which is known by the patient. The secret s may be a predefined parameter known by the patient, the patient&#39;s real identity, or personal information of the patient, e.g. his name, birthday, passport number, etc. Since the hash function is a one-way function for which there is zero-knowledge proof, the patient can prove to the doctor that the certificate with his pseudonym is indeed his, without revealing his identity. It is almost impossible to deduce the patient&#39;s real identity from the result of the hash function. 
         [0046]    In another embodiment, the additional dataset optionally comprises one or more biometrical parameters. The biometrical parameters, such as fingerprint, iris, etc. are used to describe the patient&#39;s physiological character features, and are not stored in public databases. This implementation has two advantages. The first is that the biometrical parameters are always available from the patient&#39;s body, and the second is that the biometrics cannot be linked to the patient&#39;s real identity and is difficult to forge. 
         [0047]    It is also possible to incorporate both a public key and an additional dataset in a certificate. 
         [0048]    The certificate illustrated in  FIG. 2  can be used in  FIG. 3 , which illustrates an information interchange process according to one embodiment of the invention. Let us assume that the patient has registered in hospital A and PIX manager A, and has obtained a certificate comprising a pseudo first identifier and signature of the pseudonymization service, issued by a first pseudonymization service provider. Now the patient visits a hospital in another city or country, which adopts a different pseudonymization service and a different pseudo identifier system. It is troublesome for the patient to use his original certificate in the hospital he is now visiting, e.g. hospital B and PIX manager B. In step  310  of the information interchange process, the patient first registers in hospital B by using his original certificate. In hospital B, there is a reader configured to read the certificate and extract the signature of the first service provider and the first identifier. In step  320 , the reader extracts the first identifier and the signature. It is optional for the reader to check the validity of the first identifier on the basis of the signature or to send the first identifier and the signature to another entity so as to validate the first identifier. In step  330 , a second pseudo identifier is generated, which can be used in hospital B and PIX manager B. In step  340 , the first identifier, the second identifier, and the signature of the first service provider are sent to a first identifier manager, e.g. PIX manager B. It is optional to check the validity of the first identifier in PIX manager B in step  345  on the basis of the signature of the first service provider. In step  350 , PIX manager B associates the second identifier with the first identifier. Actually, the first identifier is a pseudo identifier used by the patient in hospital A/PIX manager A, while the second identifier is another pseudo identifier used by the same patient in hospital B/PIX manager B. In step  360 , PIX manager B extracts information about the second identifier manager, e.g. PIX manager A, based on the certificate. It also allows extracting the information from the first identifier and/or the signature of the first service provider. In step  370 , PIX manager B requests the original record associated with the first identifier from the first identifier manager, e.g. PIX manager A. At least the first identifier is included in the request. It is also practical for PIX manager B to request the first service provider to find the record of the first identifier and send it back to PIX manager B. It provides an additional advantage, especially when PIX manager B cannot deduce the second identifier manager. Since the certificate is generated by the first service provider after the patient has registered in hospital A/PIX manager A, it is easy for the first service provider to find hospital A and PIX manager A. Upon receiving the request from PIX manager B, an identifier mapping unit of the PIX manager A maps the first identifier to a third identifier in step  380 , and sends a request to a database, e.g. an element in hospital A, to request the record associated with the third identifier in step  390 . After the record associated with the third identifier is retrieved, a sender in the second identifier manager sends, in step  395 , the retrieved record as the requested record associated with the first identifier to a receiver which is located in hospital B. 
         [0049]    The embodiment illustrated in  FIG. 3  clearly shows that the patient&#39;s real identity can never be sent to the visited hospital, e.g. hospital B/PIX manager B. The patient&#39;s privacy is thus protected while the necessary health record is utilized in the later diagnosis. 
         [0050]    In the embodiment illustrated in  FIG. 3 , the third identifier found by the identifier mapping unit in the second identifier manager may be the patient&#39;s real identity, but may also be another pseudo identifier which is used by the patient in hospital A. When the third identifier is a pseudo identifier, hospital A/PIX manager A can use a similar method as disclosed in the embodiment of  FIG. 3  so as to find another hospital/PIX manager which issues and uses the pseudo identifier. Irrespective of the number of pseudo identifiers the patient uses, use of the recursive method makes it easy to locate the hospital holding the patient&#39;s health/medical record. 
         [0051]    In the embodiment illustrated in  FIG. 3 , the second identifier is generated by the reader in step  330 . It is also practical to generate the second identifier by using the method disclosed in the embodiment illustrated in  FIG. 4 . After the signature of a first service provider and a first identifier is extracted by the reader in step  410 , the reader sends a request to a second pseudonymization service provider so as to generate a second pseudo identifier, in step  420 . In step  430 , the second pseudonymization service provider generates a second pseudo identifier, which can be understood by hospital B and PIX manager B, and sends it back to the reader. Optionally, validities of the first identifier and the signature of the first service provider are checked in step  425 . If the validity check fails, it is reasonable to reject the request and indicate the reason to the reader, e.g. the certificate is faked. The reader associates the second identifier with the first identifier in step  440 . Until now, the second identifier associated with the patient has been generated and can be used in hospital B. After the record associated with the first pseudo identifier is available, it is easy to associate the record with the second identifier, in step  450 , so that the patient&#39;s previous record is usable in hospital B. It is noted that the patient&#39;s real identity is not disclosed. 
         [0052]      FIG. 5  illustrates, by way of example, an information interchange system according to one embodiment of the invention. The information interchange system  500  comprises a reader  510 , a first identifier manager  520  and a receiver  530 . The reader  510  is configured to extract a signature of a first service provider and a first identifier from a certificate and generate a second identifier corresponding to the first identifier. The first identifier manager  520  is configured to associate the first identifier with the second identifier and send a request to any one of a second identifier manager and the first service provider so as to request a record associated with the first identifier. Information about the second identifier manager can be deduced from the first certificate, e.g. from the first identifier, the signature of the first service provider, or the combination. The receiver  530  is configured to receive the requested record from any one of the second identifier manager and the first service provider, and associate the requested record with the second identifier. 
         [0053]    The system  500  may further comprise the second identifier manager  540 , which further comprises a mapping unit  542 , a health/medical information database  544  and a sender  546 . The mapping unit  542  is configured to map the first identifier comprised in the request sent from the first identifier manager to a third identifier. The database  544  is configured to retrieve the record associated with the third identifier. The sender  546  is configured to send the retrieved record to the receiver as the requested record associated with the first identifier. 
         [0054]    Optionally, the system  500  further comprises the first service provider  550 , which generates the pseudo identifier and the certificate. The first service provider  550  is further configured to receive the request from the first identifier manger  520  and find a third identifier corresponding to the first identifier comprised in the received request. The first service provider  550  then requests the second identifier manager  540  to find the record associated with the third identifier. Subsequently, the record associated with the third identifier can be sent from the first service provider  550  to the receiver  530  as the record that is associated with the first identifier. 
         [0055]    By utilizing the methods and apparatus disclosed in the embodiments of the invention, it is easy to achieve the object of interchanging information, e.g. health/medical records among different health/medical information management systems while preventing disclosure of the patient&#39;s privacy. 
         [0056]    The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention or some of its features can be implemented as computer software. The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit, or may be physically and functionally distributed between different units and processors. 
         [0057]    Although the present invention has been described with reference to the specified embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. In the claims, use of the verb “comprise” and its conjugations does not exclude the presence of other elements or steps. Although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. In addition, singular references do not exclude a plurality. Thus, references to “a”, “an”, “first”, “second” etc. do not preclude a plurality. Furthermore, reference signs in the claims shall not be construed as limiting the scope.