Resumen de implementación

2.2

Related Work

Electronic Medical Records represent observations of patients taken by particular healthcare units [69]. The records contain some attributes identifying the patient, such as name, address, age, and gender. Each EMR is indexed by a unique identifier within a healthcare unit system. To link these records, research has been done on matching algorithms that do a syntactic analysis of records for the sake of determining whether they are related or not. The result of this matching process is one of the following possible results:

• Full match, • Partial match, or • Non-match.

As a result of typographical data-entry variations (e.g. ‘Collin’ versus ‘Colin’), we might not be able to get a full match for two records that belong to the same patient, and instead get a result of ‘partial match’. Although, this process might be acceptable in statistical health research where the level of accuracy required is not strong, it would not be acceptable in medical diagnosis and treatment. To improve matching accuracy for individual patient healthcare, several methods have been proposed:

String comparison: Jaro [86] introduced a string comparator that accounts for in- sertions, deletions, and transposition. The basic steps of this algorithm include computing the string lengths and finding the number of common characters in the two strings and the number of transpositions. Jaro’s definition of “common” is that agreeing characters must be within half of the length of the shorter string, and his definition for “transposition” is that the character from one string is out of order with the corresponding common character from the other string.

N-gram distance: The n-grams comparison function [157] forms the set of all sub- strings of length n for each string A and B. Then, a similarity score is computed

as follows, where ngram(A) denotes the set of n-grams derived from string A and |S | denotes the size of set S :

n-gram similarity score= 2 ×

         ngram(A)T ngram(B)      ngram(A)   +   ngram(B)          

Edit-distance: This method uses edit distance to compare two strings [88]. Edit dis- tance is the minimum number of edit operations of single characters required to transform from one string to another, i.e. to make two strings equal.

Adaptive comparator function: This method learns the parameters of the compara- tor function using training examples [50]. Zhu and Ungar [178] use a genetic algorithm to learn the edit operator costs for a string-edit comparator function. A potential data integrity problem with these matching algorithms, though, is that

we might witness accidental linking of two records that actually belong to two differ-

ent individuals with similar identifying characteristics. This risk becomes especially strong if the individual records are incomplete and contain complementary data, thus making it impossible to cross-check their similarities. In the healthcare domain the integrity of a patient’s health record is an important issue, so we don’t want to risk af- fecting the combined record’s integrity even if the occurrence rate of such mismatches is very low. Failure to find and link records concerning a patient’s allergies could be life threatening, but linking non-matching records could be just as dangerous, and might result in creating false information that could also lead to medication errors, e.g. by stating that a patient had already been exposed to or immunised against a contagious disease as a child when in fact the patient had not.

In addition, all of the above-mentioned matching methods assumed the matching process used a clear text representation of the patient’s identification data which re- veals the patient’s personal information and the source of the medical data. To over- come this problem, a new matching method has been proposed using cryptographic solutions [46]. Patients’ identification information is encrypted before sending it to the matching module. However, once the information is encrypted, the matching process

2.2. Related Work 27

becomes more difficult because a small character change in the clear text could result

in a big change in the encrypted version.

Overall, therefore, we concluded that record matching approaches are not suffi-

cient to provide accurate linkage between an EHR and its component EMRs and the linkage process itself may have privacy drawbacks. Instead, it is preferable that the patient should play a major role in the EMR linking process, since patients are (at least partially) aware of their own medical history, previous places of residence, etc.

Existing Federated Identity Management (FIM) techniques [93, 112] define how to allow users to make a link between local identities by creating a federated pseudonym identifier. The FIM architecture [103, 104] determines a set of interactions between an Identity Provider (IdP) and a Service Provider (SP) to facilitate several services such as single sign-on, attribute exchange, and account linking. An Identity Provider is an entity that authenticates users and produces authentication and attribute assertions in accordance with the Security Assertion Markup Language (SAML) Assertion and Protocol specification [5]. A Service Provider is an entity that provides web-based services to users. An entity can play the role of either an IdP, SP, or both. In our application, a healthcare provider typically plays both roles, an IdP to provide authen- tication for the users of the Electronic Medical Record system and a SP in providing access to the patients’ EMRs.

Using this approach, patients could link their local identities at different healthcare

providers in an accurate and secure way, as long as these healthcare providers are in a trust agreement [140]. The result of this linking process would be a new link between the patient’s Electronic Medical Records. The identity linking process could be accom- plished by using a federated pseudonym identifier which is associated with each local identity. This pseudonym identifier would serve as a reference for the patient [103,112] to be used when a healthcare provider wants to exchange any information about the pa- tient.

Unfortunately, however, this process fails to satisfy Requirement 3 in Section 2.1, because each healthcare provider would know that the patient maintains an EMR at

any other healthcare provider that shares the same pseudonym identifier. In addition, the patient might need to create several federated accounts in order to link identities at each healthcare provider, resulting in a complex federated identity network that will

be difficult for patients to manage.