1 of 59

OpenHIE

OpenHIE Academy Course 320

Identity Management

February 2019

2 of 59

3 of 59

3

Cleaning and Standardisation

DATABASE B

DATABASE A

Blocking/Indexing

RECORD PAIR COMPARISON

SIMILARITY VECTOR CLASSIFICATION

Matches

Non-Matches

Possible Matches

Clerical Review

Evaluation

4 of 59

Course Instructors and Contributors

Priyanka Sanikommu, MS Health Informatics, SOIC, IUPUI.
Jennifer Shivers, Regenstrief Institute, Global Health Advisor,
Dr. Shaun Grannis, Vice President Data and Analytics at Regenstrief Institute, Inc.
Dr. Richard Stanley, IntraHealth International

4

5 of 59

Key Audience(s)

Health IT Professionals (technologists, implementation leads and business analysts)
MOH / HIT Leadership (policy makers and decision makers)
Anyone interested in patient identity linking or matching

5

6 of 59

Course Learning Objectives

By the end of this course, learners will be able to:

Understand the types of challenges that identity management and client record linking and client registries can address (Value of having client linking / client registry)
Understand definitions related to Identity Management and Client Registries
Understand basic features of a client registry
Discuss the different matching algorithms typically used in matching or linking patient records from different systems
Understand typical transactions that a Client Registry should support
Provide examples of Client registry tools
Understand some frequent implementation issues

6

7 of 59

Section 2 - Identity Management Overview

7

8 of 59

Patient Identity: History

“… Each person in the world creates a book of life. The book starts with birth and ends with death. It’s pages are made up of all the principal events in life. Record linkage is the name given to the process of assembling the pages of this book into one volume. The person retains the same identity throughout the book. Except for advancing age, he is that same person …”

- Dunn, 1946

9 of 59

Client Registry Definition

Sometimes called a Master Patient Index(MPI)

A client registry (CR) checks the patient from multiple sources and matches/links demographic data. A client registry supports the ability to manage patients, monitor outcomes, and conduct case-based surveillance by facilitating information exchange through:

supporting exchange of patient information between disparate systems.
holds patient identifiers and may include patient demographic information.
links identities across systems

9

A Client registry may also be referred to as Master patient Index. Coming to the definition: A Client registry checks the patient from multiple sources and matches/links demographic data to create a link to any other identities that this patient has in other point of care systems (POS).

The better that you are able to match the records between systems , the more effectively you can support exchange data and give patients and clinicians more accurate information, as well as reduce costs by preventing duplicate lab tests. Better matching also allows for better support for more robust research using real world data.

A client registry holds the patient identifiers ( family name, given name, date of birth, Contact number, a unique country identifier (if available), Address, photo etc. ) including the demographic information. It is a necessary tool for public health to help manage patients, monitor outcomes, and conduct case-based surveillance by facilitating information exchange through:

supporting exchange of patient information between disparate systems.
holds patient identifiers and may include patient demographic information.
links identities across systems

A critical component of an HIE are registries, such as those to manage a shared, canonical facility list, practitioners, and patients.

10 of 59

Patient Matching: Synonyms and Definition

“Patient Matching” → “Patient Linkage”
“Record Matching” → “Record Linkage”
“Identity Management”

10

Entities are typically individual persons, but can be facilities, health workers, organizations, etc.
Records contain fields describing the entity.
These fields can include: “Unique” ID’s, Names, birth dates, addresses, Sex, Parents’ names, tribe, telephone numbers, etc

Identify records that represent the same entity (patient).

Before we dive in too deep, let’s provide some background on terminology that people use when talking about identity linking and identity management.

Patient matching produces patient links

record matching produces record linkage

The goal is to manage a patient’s identity in a way that allows linking records across multiple point-of-care systems

- {Patient/Record} {Matching/linkage}

There are lots of synonyms and lots of different ways of describing patient identity management. But it is really all about identifying records that represent the same entity. The word entity is used instead of patient or person because matching can be performed for families, twins, facilities & organisations. We usually use multiple fields.( Unique” ID’s, Names, birth dates, addresses, Sex, Parents’ names, tribe, telephone numbers, etc ).

11 of 59

Client Registry ≠ Shared Health Record

A Client Registry provides a unique identifier, it does not implement a Shared Health Record.
A shared health record (SHR) may be created for patients using identifiers in the Client Registry.
There may exist separate governance, privacy, security, and other requirements for a Shared Health Record.

11

12 of 59

Basic features of CR

Entity matching - Identify duplicate patients

configurable algorithms allow for matching schemes to be tailored to the needs of the context

Assigns and looks-up unique patient identifiers,
Maintains a central registry of patients and their demographic data,
Allows connections from diverse point of service systems, such as electronic medical record (EMR) systems,
Links patient records and breaks links.

12

13 of 59

What is in a Client Registry?

What may be stored

Patient, system identifiers
Demographic information

Date of birth
Place of birth
Patient Names
Gender
Addresses
Marital Status
Telephone / email addresses
Multiple birth status/order
Death status / date

Relationships

Mother/father/next of kin

Facility the patient demographics came from

What is not stored

Patient conditions

E.g. HIV Status
Diagnoses / Chronic Conditions
Allergies

Encounter data

Visit information
Appointments
Physician information

Facility information

Beyond the facility a patient is assigned to

13

This slide shows some of the key attributes that may be included in a client registry. There may be some facility information in a Client Registry. This is because, to differentiate where that information came from and to distinguish between different source of identity.

some of the attributes that might be in a shared health record are shown on the right side of the slide. This is to help you understand the difference between a client registry and a shared health record. Note that the client registry focuses on attributes that help identify the patient and the shared health record focuses on creating a longitudinal record of the Patient’s care

14 of 59

Section 3 - How does a CR Work?

14

15 of 59

Types of challenges That client registry and client record linkage can address:

Deduplication (within a single system)
Linkage across systems

To link a patient’s records across EMR / Community systems.

For example: challenge to match a patient who has got their name recorded different in different hospital registers.

To link lab results for a patient with their EMR data
To tabulate health system metrics across systems

15

16 of 59

Silent Transfers

16

January - ART Clinic

March - ART Clinic

17 of 59

Multiple Facilities / Client Identities

17

ID	FN	GN	DOB	NIN
456	BLESSING	MAKUMBE	09-09-84	CF-000-123-456

ID	FN	GN	DOB	NIN
2001	MAKUMBE	BLESSING	09-08-84	CF- 000-123-456

ID	FAM	GIV	WARD
340393-302921-1974S	MAKUMBE	BLESS	Kaloleni

ANC Clinic

ART Clinic

Hospital

Let’s look at another scenario where record linking could be helpful.

One patient can go to multiple facilities or service providers for many different reasons.
One example of the potential for a patient’s data spread across multiple systems is a pregnant woman.
In many countries a pregnant woman may receive care at the clinic near her home. but she may also receive HIV support at an HIV clinic. She may have complications that require her to deliver at a hospital. This results in the records for her care being in three different systems. This results in three different IDs. One for each system. i.e it results in same patient’s data is located in multiple unlinkable records across three different EMRs or three different clinics with their own identity records.

How it works

The Client Registry links patients based on a unique identifier.
The unique identifier is used to combine a patient’s records from each system

Example of value add

Data managers can deduplicate records and more accurately calculate indicators

18 of 59

Multiple Identities and Monitoring

18

ANC Clinic

ART Clinic

Hospital

Data Manager

ID	FN	GN	DOB	NIN
456	BLESSING	MAKUMBE	09-09-84	CF-000-123-456

ID	FN	GN	DOB	NIN
2001	MAKUMBE	BLESSING	09-08-84	CF- 000-123-456

ID	FAM	GIV	WARD
340393-302921-1974S	MAKUMBE	BLESS	Kaloleni

District Data Manager

Duplicate identities in the monitoring system

The district data manager receives the data from the three different EMRs and has no easy way of determining that these are the same patient.

Scenario

One patient can go to multiple facilities or service providers
Often, EMRs are often not networked
Data may be entered end of the day
the scenario that we see here is - A pregnant women with the name Mukambe Blessing went to ART clinic for her regular gyenic checkups. She had to visit another clinic for her dermatology issues and she was registered with a different date of birth and year at the ANC Clinic. Later that year she had to visit an ER as she fell from the stairs and had a sprained ankle where her details were entered into the registry but did not mention the D.O.B in the records. Making the process of identifying the patient more challenging.

If we add record linking or an identity management system to that example. It would work like this:

The Client Registry links patients based on a unique identifier.
The unique identifier is used to combine a patient’s records from each system

Examples of value add

Clinicians provide care based on a fuller, recent health history.
Data managers enjoy decreased instances of duplicate and incomplete records.
Policy makers use more accurate data as to lost to care (LTFU).

We know that multiple identities can arise for a variety of reasons. That's a duplicate. It shouldn’t happen. Links across the systems, so if a patient goes to a clinic and then to a laboratory system if they are capturing identity and one at the Clinic system. Duplicates occur because of typically real issues with the data they can be tricky to disentangle linkages across that, they occur because they should and the data quality is typically much higher. It is easier to find links than to just find duplicates.

We can break them into those two groups - dupes Versus links and then in healthcare linkages can occur for a variety of use cases ranging from the global HIE approach to link everything together for all of the different data sources within a given scope. That is huge and immunization registries are another linking lab systems like for the HIV’s case linking labs to EMR is another use case.

19 of 59

Multiple Identities and Monitoring

19

ANC Clinic

ART Clinic

Hospital

Linked CR - ID 2345

ID	FN	GN	DOB	NIN
456	BLESSING	MAKUMBE	09-09-84	CF-000-123-456

ID	FN	GN	DOB	NIN
2001	MAKUMBE	BLESSING	09-08-84	CF- 000-123-456

ID	FAM	GIV	WARD
340393-302921-1974S	MAKUMBE	BLESS	Kaloleni

District Data Manager

Unique Identity for the Same Person

If we add record linking or an identity management system to that example. It would work like this:

The Client Registry links patients based on matching algorithms and creates a unique identifier.
The unique identifier can then be used to combine a patient’s identities from each system

Examples of value add

Data managers enjoy decreased instances of duplicate and incomplete records.
Policy makers use more accurate data as to lost to care (LTFU).
this can be the foundation for Clinicians provide care based on a fuller, recent health history.

In this scenario, the Pregnant women from the previous example can have her demographic data evaluated and the records from each of the systems can be linked using a unique ID.

In this example, in the client registry, the patient was given a Linked CR- ID 2345 to identify and link the patient records.

This allows the district data manager to be able to see that the person is only counted once in the health system metrics.

20 of 59

Uniquely Identify Patients in Labs

20

Clinic EMR

ART lab

ID	FN	GN	DOB	NIN
456	BLESSING	MAKUMBE	09-09-74	CF-000-123-456

ID	FN	GN	DOB	NIN
222	BLESSING	M	09-09-74	CF-000-123-456

Two records are not linked

21 of 59

Use cases

21

Vaccine clinic 1

Vaccine clinic 2

Vaccine clinic 3

ID	FN	GN	DOB	NIN
456	Blessing	MAKUMBE	09-09-74	CF-000-123-456

ID	FN	GN	DOB	NIN
248	BLESSING	Aleya	07-10-99	CF-000-123-456

Not registered - Free vaccination program

Children immunizations:

There are incidents where children are re-immunized multiple times because they can't be found in the systems even though they have been vaccinated but a few might have records.

Scenario here is a child was taken to vaccination clinic to get vaccinated with hepatitis A and B first dose at vaccine clinic 1, After few months the same infant was taken to another clinic for an MMR (measles, Mumps and rubella) vaccine and they were offering a free hepatitis vaccination for kids that day so the father gets the infant vaccinated again as he was not aware of previous vaccinations nor it is in the records as the baby was registered under the name of his mother when vaccinated for the first time. Again the baby was taken to a different clinic for second dose of hepatitis B and did not find the records for the first dose so the baby was vaccinated again as he couldn’t be found in the records.

22 of 59

Identity Management Motivation

22

Clinical information is fragmented across many independent databases using different identifiers
Fragmented data directly impacts challenging for such uses as:

Treatment, Payment and Operations (TPO)
Public Health/Administrative Reporting
Outcomes management
Vital status determination
Research

We have provided a couple of scenarios to give examples of where identity management can benefit from being able to link a patient’s records across systems or to identity a patient’s duplicated identity within a single system

The case for using identity management becomes increasingly important as we move toward being able to collect and manage patient-level records.

- Increasingly health care information is fragmented (distributed) across many independent databases and systems, both WITHIN and AMONG organizations as SEPARATE ISLANDS with different patient identifiers created by the paper and or electronic systems used at the point-of-care.

- This is the case FOR DATA collected WITHIN an institution where there may be multiple identifiers, and FOR DATA collected about the same patient at

- different health care institutions

- different pharmacy systems

- different payers, and so on.

- This situation may reduce a care provider’s view of the patient’s full history and care and therefore may impact care decisions or cause duplicate testing

- This situation INTERFERES with the aggregation of information as needed for:

- public health reporting

- clinical research

- outcomes management, and health care policy

Aggregation is important NOT ONLY to determine a patient’s health care status, BUT ALSO for population based studies.

Record linkage is the process of combining information about an individual, family, or entity residing in one or more databases.

To provide good care, public health and accurate health system metrics, there is a need to support linking patient identities across systems.

In the next section, we will share a bit more information about how that record linking can be done.

23 of 59

Section 4 - Patient Matching

23

24 of 59

Barriers to Accurate Patient Matching

Recording Errors

Phonetic (“Shaun”, “Sean”, “Shawn”)
Typographical�(Smith → Snith, “07” → “01”)

Changing Identifiers

Last Name (Marriage)
Geographic location (Home address, etc)

Sharing Identifiers (Country based identification numbers ex: SSN (USA) etc.)
Identifiers Limited or Unavailable (missing)

24

There may be other factors unique to your context.

In the last section, we noted some of the medical and health reasons for being able to link records across systems.

The following are some of the barriers for patient identity matching or record linking. These challenges can be unique to each culture, language and context. But here are some of the key challenges:

Phonetic recording errors, For example: If somebody says their name is shaun, there are lots of different ways to spell the name “shaun”

Typographical errors: for example: sevens and ones look a lot a like.

Changing identifiers:

in some cultures, Last Names are changed when people marry
Geographic location (Home address, etc) can change or be difficult to describe

People sometimes Share Identifiers (Country based identification numbers ex: SSN (USA),etc.). A child may not have a SSN yet so they use their parents SSN so the data is missing. We see that a lot with newborn.
Identifiers Limited or Unavailable (missing)

25 of 59

Ideal Identifier Characteristics

Unique�(eg, fingerprint, Iris, DNA, National ID)
Ubiquitous�(eg, Name, DOB, Sex, Eye Color)
Unchanging�(eg, DOB, Sex, Given Name, DNA)
Uncomplicated�(eg, Name, DOB, Sex)
Uncontroversial�(eg, avoid sensitive data)
Easily and Inexpensively Accessible

25

No identifier meets all of these characteristics

If we think about the ideal characteristics of a patient identifier, the following come to mind:

Unique - people have certain unique identifiers like fingerprints DNA, National ID. Easy to identify. �(eg, fingerprint, Iris, DNA, National ID)
Ubiquitous- Everybody has it and it is available to everyone like name , DOB, Sex, eyecolor etc. �(eg, Name, DOB, Sex, Eye Color)
Unchanging - DOB, DNA, and gender with some exceptions, names sometimes can be changed or people can have nicknames. �(eg, DOB, Gender, Given Name, DNA)
Uncomplicated - some identifiers are very long, complicated to obtain. �(eg, Name, DOB, Gender)
Uncontroversial - some people don’t feel comfortable sharing country-level identities or biometrics. �(eg, avoid sensitive data)
Easily and Inexpensively Accessible.

No single identifier meets all of these characteristics.

26 of 59

Potential Identification solutions

Universal patient identifier (UPI)
Pros:

Can simplify matching and

increase matching accuracy.

Cons:

Recording errors

Sharing ID’s

Lost ID’s

Controversial (in some contexts)

26

✅ Unique +/- Ubiquitous ✅ Unchanging +/- Uncomplicated ❌ Uncontroversial +/- Easy/Inexpensive access

27 of 59

Potential Identification Solutions

Biometric Identifiers

Examples: fingerprint, voice, retinal,
vein scan
Facial recognition.
Pros:

Highly specific to an�individual (unique?)

Cons:

Require proprietary hardware for all

data generators

Privacy/Security concerns

27

✅ Unique ✅ Ubiquitous ✅ Unchanging +/- Uncomplicated ❌ Uncontroversial ❌ Easy/Inexpensive access

Biometric Identifiers

Examples: fingerprint, voice, retinal,
vein scan
Facial recognition.

Pros:

Highly specific to an individual (unique?). Mostly unique although some people can share similarities.

Cons:

May require proprietary hardware for all data generators. There are lots of different types of fingerprint scanners that are not interoperable and compatibility varies with which vendor we use. People are also Concerned about how their biometrics are used outside health care.
Privacy/Security concerns - there are always loops holes to such technical solutions. For example: People who work their hands, their finger might get worn or damaged.

Biometrics provide a powerful tool to identify patients, instantly finding the right record with the tap of a finger. There are examples of this technology being used in the field. For example, Simprints, example of a biometric provider, is working with partners in Dhaka to ensure every mother and child has access to care.

28 of 59

Potential Identification Solutions

Patient matching algorithms:

Establish identity using multiple�patient attributes
Pros:

Leverages existing data
Does not require biometrics�or UPI

Cons:

Imperfect: False positives/negatives
Accuracy dependent on data quality

28

+/- Unique ✅ Ubiquitous +/-Unchanging ✅ Uncomplicated ❌ Uncontroversial ✅ Easy/Inexpensive access

29 of 59

Patient Matching Terminology

True match/True link/True positive�Truly matching records declared to be the same entity
False match/False link/False positive�Truly non-matching records declared to be the same entity
True Non-match/True Non-link/True negative�Truly non-matching records not declared to be the same entity
False non-match/False non-link/False negative�Truly matching records not declared to be the same entity
We have Few more matching terminologies - Potential pairs/Links, Blocking/ Grouping, Field Agreement weight/score ….etc.

29

As we think about patient matching, there are some key terminology and concepts.

The first four terms have to do with the accuracy of the matching algorithm.

True match/True link/True positive (correctly matched)

Those are truly matching records that the matching has said it is a match. Truth is a match and the algorithm says its a match.

False match/False link/False positive (incorrectly matched)

In Truth a record is not a match but the algorithm says it is. We do not like this in healthcare. We do not want to combine two different people’s medical records. High risk of patient privacy violation. THis is why we do record linking so that if a mistake in matching is done, we can unlink the records. Our algorithms need to be tuned for each context to avoid this situation.

True Non-match/True Non-link/True negative (Correctly not matched)

Truly do not match and shouldn’t be matched and the algorithm says that they do not match.

False non-match/False non-link/False negative (The identities do match, but the algorithm did not perceive the match)

These records really match but the algorithm says it doesn’t.

Here are some other terms you will hear:

Potential Pairs/Potential Links�Record-pairs that have not been declared a match or non-match
Blocking/Grouping�Method to limit search space for potential links, usually by forcing exact match with one or more fields. (Analogous to sorting socks by color before pairing)

One example is to only search for matches within a certain region that the person if from or within an age or gender grouping. These blocking methods need to determined by the context.

Field Agreement Weight/Score �Value assigned when two fields are declared to agree
Field Disagreement Weight/Score �Value assigned when two fields are declared to disagree
Record Pair Score/Composite Score/Global Score�Value derived from individual field contributions (typically the product or sum of field weights) and denotes the matching score generated by the algorithm.
Score Threshold�record pair score above which a match is declared and/or below which a non-match is declared

30 of 59

Patient Matching Terminology

30

TNM

TNM+FM

Matching System Declaration

“Truth”

True Match

True Non-Match

True Match

True �Non-Match

True Match

False �Non-Match

False Match

True �Non-Match

TM

TM+FM

“Pos Predictive Value”

or “Precision”

TNM

TNM+FNM

“Neg Predictive Value”

TM

TM+FNM

“Sensitivity” �or “Recall”

“Specificity” �

We described these terms in the previous slide. This may provide a little more detail about how we think about matching.

Positive predictive value: True match/ True match+ False match

Negative predictive value: True non match / True non-match + False non-match.

Specificity: True match/ True match + False Non match

Sensitivity: True Non match/ True nonmatch + False Match.

You tend to optimize for only one of these measures. And when you choose one of these measures, the other measures are going to suffer.

If I want to be very sensitive, meaning I capture all of the possible matches out there. For example. Let's say that I want to identify every person with COVID in a state, all of them. Well, one of the ways my algorithm can do that is I'm going to say, You know what? Every person in Indianapolis has COVID period. By declaring that my algorithm has found every person who was positive for COVID, right? They've just include a lot of people who don't have covid. Let's say that 20 percent of people in Indianapolis have COVID. If I want to make sure I find that 20 percent, let's say that's 200 thousand people. I just say, you know what? I'll million people in Indianapolis have COVID. I found that 200 thousand they are in there somewhere. That is a highly sensitive algorithm, captures all of the true cases. But what have we introduced? A ton of false positives. So our positive predictive value is going to be very low, our specificity is going to be very low. There's a trade off. If I want to optimize my specificity or I say, You know what, I really want to identify everyone who is not COVID positive in Indianapolis. I'm just going to say nobody has COVID in Indianapolis. Now, the 200 thousand who are positive are going to be false. Negative, excuse me, false, false negative. So I've declared 200 thousand people negative for COVID when they're not. So my specificity will be a 100 percent. I have found all the negative cases by declaring everyone negative. I've introduced to a lot of false negatives. There's a trade-off here. We try to optimize, right? We're trying to find some middle ground.

31 of 59

Patient Matching Methodologies

31

Statistical Matching

Deterministic

Probabilistic

Increasing Complexity

Machine Learning

Hybrid Solutions

32 of 59

Deterministic Matching

‘Rules-based’ or ‘Heuristic’
Accuracy is highly dependent on presence of discriminating identifiers (national or local ID, etc)
Rule-based, eg declare a match if exact match on:

National ID + DOB
Full Name + Address
etc.

32

A deterministic method searches for an exact match between attributes, while a probabilistic method searches for an approximate match between two records. For example, searching deterministically would not find a match between the names Thandi and Thandie, but a probabilistic method would flag them as a possible match. This combination of matching methods would allow the MPI to link two records where a client used different names (e.g., their English and African names) on different occasions, but other aspects of their information (ID number, age, address, etc.) match up.

other aspect of deterministic is really that they use predetermined rules, unique identifier, DOB, and Last name matched then declare it a match. In the pro’s it doesn’t say much about rules. It is generally predetermined - they makeup the rules even before having any idea about the data, how it is going to look like, the rules are preset. It is highly specific. You wont get false positive matches but you probably will miss some matches.

Probabilistic data on the other hand is adaptive, accommodates the data. They tend to reduce the no. of miss matches but sometimes they can do that at the cost of bringing in false matches. To handle this, Incorporating some business rules and deterministic rules on the back end of the probabilistic algorithm aids in eliminating those matches.

Probablistic is the best way to go but it requires sophistication. Experts should intervene to know that it is configured appropriately which is why people tend to move toward more rule based or deterministic.

If One wants to use deterministic and rule based matching they should include more rules that they believe in and use fuzzy matching when they do that. if they have the resources and capability to use probabilistic algorithms, that is preferred as probabilistic matching gives more accurate matching.

33 of 59

Patient Matching Methodologies

Deterministic/Heuristic

Rapid Implementation
Simple calculations
Relies on accurate and consistent data
May not generalize well to other data sets

Probabilistic

Complex implementation
Computationally intensive
More forgiving of data errors
Algorithms adapt to data being linked

33

34 of 59

Fuzzy Match

Non-exact agreement, allows for errors:

“If last name agrees on first 6 characters then declare agreement”
“If birth date is within 1 month, then declare agreement”

To loosen agreement, string comparators or phonetic transformation functions may be used:

Soundex - Phonetic
NYSIIS - Phonetic
Levenshtein Edit Distance - Comparator
Jaro-Winkler Comparator - Comparator
Longest Common Sub-sequence - Comparator

34

the concept of fuzzy match is that to accommodate some minor variations. so sometimes there might be ‘shaun’ and ‘shawn’ are not the same but they are close. so there are ways of accommodating that. There are more errors at the end of the string, like, at the end of the name than at the beginning.

on-exact agreement, allows for errors:

“If last name agrees on first 6 characters then declare agreement” (Most often 4 characters) - you’ll have greater agreement there.
“If birth date is within 1 month, then declare agreement” (with numbers - 1 look like a 7, 8 looks like a 5 so when numbers are off (ssn, dates) when there is variariations.

To loosen agreement, string comparators or phonetic transformation functions may be used:

Soundex - Phonetic
NYSIIS (newyork state identification and intelligence system) - Phonetic

Phonetic parts - Soundex and NYSIIS are examples of rules that we can use to deal with those slight variations.

Levenshtein Edit Distance - Comparator
Jaro-Winkler Comparator - Comparator
Longest Common Sub-sequence - Comparator

bottom bullets are more of the algorithmic comparators. These are called string comparators - take the entire string and they compare them using different algorithms like how close are these strings really, what sort of differences do we see. they create a score typically between 0-1 with 0 being no agreement and 1 being 100% agreement or close to that. That information can be used in the matching algorithm to support the waiting and determination of the identity matching.

35 of 59

Probabilistic/Machine Learning

Implements a statistical model for matching
A common model is Felligi-Sunter maximum likelihood model
Establish parameters for model using machine learning algorithms (EM) or bootstrap review
Maximum Entropy Model also used

35

36 of 59

Probabilistic Linkage Overview:�Human Review Thresholds

36

When using matching algorithms, you often generate a confidence score that specifies how confident the algorithm is with the match. When testing the matching algorithm and fine tuning the matching, you will note that matches with a score less than a specific confidence score are not matches (this is your lower threshold) and matches with a higher confidence score are matches this is your upper threshold. In most cases, there will be some area of scores that contain matches and non-matches. Depending upon your use case or the health problem you are addressing, you may determine that a human reviewer needs to look at these cases to determine which are matches.

In reality most USES OF probabilistic algorithms incorporate a HUMAN REVIEWER into the process. To do that you need to have a matching score that

THAT IS, any record pair below a LOWER threshold is considered a non-link, and above an UPPER threshold is a considered a TRUE-link.

So, the results of most probabilistic methods are ACTUALLY probabilistic PLUS humans, and they work quite well.

Question: If human review combined with probabilistic works well, why WOULDN’T we want to use it?

One SITUATION is when we cannot afford the high cost of a human operator (human review can require thousands of man-hours of work), or because privacy concerns dominate. In such a case, we may wish to AUTOMATICALLY link PATIENT DATA using all available demographic identifiers. Once linkage is established, patient identifiers may be removed, leaving only unidentified clinical data.

Therefore, we wanted to evaluate a probabilistic method without human intervention,

(or with a single threshold). In doing so that we can make the right methodology choice (either probabilistic or heuristic) when we cannot afford the high cost of a human operator, or because privacy concerns dominate.

We can remove the human operator by picking a single threshold above which we declare a link and below which a non-link.

We hypothesize that a probabilistic linkage method will perform better than our EMPIRICAL (exact-agreement deterministic method) because probabilistic methods produce scores that are tailored to the unique characteristics of the specific records being linked. (That will be explained shortly.)

37 of 59

Section 5 - Architecture

37

38 of 59

Central Registry

38

Contains patient identifiers with pointers or links to to point-of-care sources.
No clinical data contained in the repository
Contributing data sources send patient demographics, matching can be performed in real-time or near real-time

Name	Birth Date	Sex	Source
Smith, Jane	12-Oct-1978	F	Vaccine Clinic
Jones, Fred L	07-Feb-1982	M	Hospital A
Smith, Jayne	12-Oct-1980	F	Clinic B
Williams, Mary	20-Dec-1985	F	Clinic A
Mary, Williams	20-Dec-1986		Hospital B
Jones, Freddy	01-Feb-1988	M	Clinic A

39 of 59

Patient Registry

39

Clinic A

Jill Receives Immunizations @ Vaccine Clinic

Data recorded in an immunization registry

Jill Receives Immunizations and other care (measurements, labs, diagnoses, etc) @ Clinical Practice

Data recorded in an EMR

Immunization Registry

40 of 59

Client Registry

40

Immunization Registry

Clinic A

Patient ID: 123LMNOP

Name: Minnie Mouse

hiDOB: 01/01/2011

PAN: N/A

Address: S.V.Road

City:Disney

State: Land

ZIP: 400 056

Patient ID: 6789XYZ

Name: Minnie Mouse

DOB: 01/01/2011

PAN:123-45-6789

Address: S.V.Road

City: Disney

State: Land

ZIP: 400 056

Client Registry / Central Patient Index

Global ID: 45678

Name: Minnie Mouse

Lots of Demographics..

MRF1 ID: OU81247

MRF2 ID: 4564356

IMM REG ID: 123LMNOP

CLINIC A ID: 6789XYZ

41 of 59

Client Registry

41

Clinic B

Immunization Registry

Hospital A

Hospital B

Clinic C

Central Patient Registry

Clinic A

42 of 59

Section 6 - Governance and Implementation Considerations

42

43 of 59

Matching Algorithm Implementation Recommendations

There is a spectrum of matching options from simple matching, exactly matching key fields, to complex matching, configuring an algorithm that establishes weights for particular data values.
Using too simplistic of an algorithm may result in a higher percentage of duplicate records.

43

44 of 59

Matching Algorithm Implementation

Recommended Process:

Performing initial data analysis to identify candidate fields for matching and blocking
Validate candidate fields
Identify blocking schemes
Configure / parameterize matching algorithm (deterministic or probabilistic)
Evaluate results and tune the algorithms.

44

Whatever matching algorithm option is chosen, it is recommended that implementers think about the process that they will use to tune and verify the matching algorithm.

The recommended process involves:

1. Performing initial data analysis to identify candidate fields for matching and blocking - in this step, consider the quality and completeness of the patient demographic data elements that can be collected from the point-of-care systems that are in your project scope.

2. Validate candidate fields - You may want to get sample data sets from the different point of care systems that are in scope and look at the attributes that are available in each system and consider options for helping get complete and accurate information.

3. Identify blocking schemes - Blocking schemes are search practices that enable the search engine to reduce the number of records to compare in detail. For example, if gender is a reliable attribute that is completed in point-of-care systems, you may want to only do detailed comparison on records with the same gender and gender blank. This type of approach may reduce the records to search by around 50%. Based upon the attributes available in the context, are there common blocking schemes that can be used to reduce the records that have to be compared more thoroughly.

4. Configure / parameterize matching algorithm (deterministic or probabilistic)

To evaluate the patient-matching algorithm, it may be necessary to use production data. If so, the use of this data needs to be controlled and managed under the privacy guidelines created for the project. Most likely, you’ll need to identify the expected matches by hand to determine the expected results of the algorithm.

5. Once you have configured the algorithm, you may need to tune the matching to work toward the highest number of true matches without false positives.

45 of 59

Client Registry Governance

Compliance and mandate:

Patient privacy (PII): Establish a minimum data set
Data locality
Operational governance and management
User Roles and Responsibilities
System Data Access / Use
Data Provenance
Security: System and user authentication, authorization
Auditability and Traceability

45

These are the aspects that need compliance and need to be mandate:

Patient privacy (PII): you will need to know any privacy policies and regulations that are in place for the context. You will also want to Establish a minimum data set that can be used for patient matching.
Data locality: Governance decisions need to be created to help determine where the client information can be stored and how it will be transported. For example, the governance structures may need to determine that Client registries are an in-country service and therefore client demographic data cannot be transported or stored outside of the country.
Operational governance and management - A clear governance structure needs to be in place to manage these concerns and others. In addition, there will need to be policies and procedures established
User Roles and Responsibilities: Because of best practices and data privacy, the governance structure will need to determine Who manages a CR and who has access to the data. There will need to be system and process controls to protect access to the data.
Data Access/ Data Use : Which trusted systems can use a CR and what are they allowed to do? The interoperability layer can help control systems that can send or receive information from the client registry, However, there also need to be clear governance decisions on the trusted systems that will be able to record demographic record in the client registry and decisions about which point-of-care systems can retrieve linked ids from the client registry.
Data Provenance - It is important to track which demographic attributes came from which point-of-care sources. Also, if the system is creating what is called a “golden record” or a record of the demographic information that is deemed to be “correct” then there will need to be governance decisions about how priority is given to data from specific-point of care systems. In other words, which systems are deemed to be most “reliable”. Is it just the latest data is the most “correct” or is that data from an EMR or hospital might be more reliable than data from a different source.
Security: System and user authentication, authorization - Because patient demographic information is involved, Both authentication (determining who a system or user is) and authorization (determining what functions the system or user can perform) are needed to secure the client registry. Additional security to assure security in storing and managing access at the point-of-care, during transmission to a central client registry and during storage and management in the health exchange are required to secure the information. Both procedural security practices such as limiting access to physical hardware and password policies and technical measure such as encryption during transit and node authentication should be aligned with local regulations and best practices for protecting data.
Auditability and Traceability - auditability is the ability to determine what was changed, when it was changed and by whom (or which entity). Traceability is the ability to determine where information came from. both auditability and traceability needs and requirements should be considered when establishing a system.

46 of 59

Key Governance Considerations

Terminologies
Application Programming Interface (APIs)
Algorithms and decision rules
Governance of customization
Governance of deployment

46

Governance around decisions for patient matching

The following are the types of considerations and governance decisions that may need to be addressed as teams begin to implement identity management and linking solutions.

Terminologies, Concepts, ontologies, etc. is a governance decision. Laws vary from state to state and country to country considering the marital status. For example: A country or state may define domestic partnerships as legal or illegal. They may define cohabitation as marriage after a no.of years. There may be Legal definitions and de facto definitions for terms in the world to build information systems. They may have rules around. How each district or state defines marriages might be different. There may be different categories. In this way when collecting information, for example: capturing something on a driver’s license or capturing something on a tax form in OpenMRS there may be legal definition and a de facto definitions that people use around the world to build information systems. When you are using client registry this is very much at the forefront of decision making..

HL7 FHIR is well known for its efficiency with sharing the patient data across the systems. Everyone wants to use FHIR but the reality may different for different point-of-care systems.

EX: If we download personal medical record from two different providers,

The provider who’s organisation is associated with the university,
Downloaded the records, they were in C-CDA format

Got Vaccinated, Signed Up for the medical records site that holds my vaccination record, this is another medical group. They are in CCDA format.

downloaded the documents from the mobile. They were in different format.

Existing Huge legacy of health information systems and it is not using FHIR.

2) APIs - There may be governance or architecture decisions on How source systems connect to a client registry, what API will they use to do so?

Is it part of the burden of the source system to provide an API? Does the API have to support FHIR and what about legacy EMRs or source systems?

For example, if a medical record wants to connect to the Apple health system App, you have to use (API) application programming interface specified by Apple.

There is a governance around what API (what programming interface we are using) to make one’s client registry service available. There need to be decisions around how applications will interact with the service and how data can be sent to the client registry. If these decisions on access are made by individual programmers, the connections with the Client registry will all be unique and difficult to manage. So these types of decisions need to be governance or managed as a strategic level.

3) Algorithms and decision rules:to match the patient’s the first thing is to figure out what the rules are going to be. what data attributes used to match such as the patient's marital status, birthdate, First Name, Last Name, whatever, How are you going to do that? Client registry products generally require decisions to be made about what attributes to match on.

4) Governance of customisation: There needs to be governance about how a tool like a client registry will be configured and if there will be any customized code needed to support your implementation.

Privacy and security

Client registry only uses demographic data, That could be violated, there could be situations in which we use someone’s condition to match. In the IT world we say we separate concerns, in the IT security world what that means is we are reducing our attack surface, that means there are fewer entry points for someone who has ill will, they can only get demographic data and not clinical data. It is not just by limiting your attack surface. Limiting which systems can even talk to a client registry. How do you further lock it down?

5) Governance of deployment:

One needs to know if they are deploying for a local original initiative or are they planning for a nation. Scale is important here. If someone is building for the much larger scale then the no. of stakeholders that need to be engaged are much greater. Building a national identification scheme is primarily a governance challenge, not a technical challenge and understanding who all of the stakeholders are that have an interest in identity.

Governance deployment:

Building a national identification scheme is primarily a governance challenge, not a technical challenge.
Understanding who the players are, understanding the status of the identity strategy for a country is important.
It is important to understand who has access to the patient’s private, personal, & confidential data and identity for what purpose of being very clear about what the use cases are, While changing Healthcare data sometimes we only trust some of the sources for identity.

Are they deploying for a local original initiative or are they planning for a nation. Scale is important here. There are many identification projects that were only designed to work locally and really hadn’t contemplated much longer scale. If they are designing something locally that isn’t necessarily intended for longer term. There is a lot more flexibility in the approach. If they are building for the much larger scale then the no. of stakeholders that need to be engaged are much greater. Building a national identification scheme is primarily a governance challenge, not a technical challenge and understanding who all of the stakeholders are that have an interest in identity.

Understanding who the players are, understanding the status of the identity strategy for a country is important. Often countries think about identity first and foremost for healthcare but more for tax purposes and other reasons like boarding, healthcare is often as you know secondary or tertiary priority. We actually saw that in Rwanda. Rwanda had a national ID. But they were not willing to share it with the ministry of health so the ministry of health had to create their own unique ID for patients, do a round of identification

47 of 59

Implementation decisions

Put your emphasis on high quality data rather than a complex algorithm.
Matching accuracy can be impacted by the poor identifiers.

“Not let perfect be the enemy of good enough”.

47

48 of 59

Conditions for Implementation

What are the conditions required for a Client Registry to be implementable?

Asynchronous not synchronous

Requires limited connectivity, not real-time.
Electronic clients data, not paper client records or an EMR
Occasional electricity

Incremental deployment

Regional or a network of EMRs before national

48

49 of 59

Where to Start

How are patients identified today?

Is there a unique ID?
Is patient demographic data electronically captured?

What use cases do you want to start with with?

Do those require a patient registry

What are some example of success?

See the OpenHIE
Getting started guide - reference here ?

Governance
Think about the privacy and security needs for your use case

49

As we think about getting started with a CR implementation, there are some basic questions to start with:

Begin by understanding how patients are identified today
Identify the first use cases that need support for patient record linking

being very clear about what the use cases are. While changing Healthcare data sometimes we only trust some of the sources for identity. Because sometimes identity needs to be updated periodically. people change their names, change their location etc. Some sources of information may be more authoritative than others and deciding that approach to determining authoritative is the part of governance. Deciding who can influence or inform identity Is an important question to ask. That can be answered in a variety of ways. This is an important aspect of the governance process.

Look to the OpenHIE community that focuses on Patient Identity management and other OpenHIE resources on the OpenHIE web site.
Ensure that there is a governance structure in place to help with the implementation decisions
Privacy and security
It is important to understand who has access to the patient’s private, personal, & confidential data and identity and for what purpose that data can be accessed?

50 of 59

Section 7 - Examples

50

51 of 59

Example CR Landing Page

51

52 of 59

Patient Record View

52

53 of 59

Standards

OpenHIE standards describes the data exchange standards.

PDQ - The Patient Demographics Query (PDQ) Integration Profile lets applications query a central patient information server and retrieve a patient’s demographic information.

PDQm - The Patient Demographics Query for Mobile (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications. The functionality is identical to the PDQ Profile described in the ITI TF-1:8.

https://wiki.ohie.org/display/documents/OpenHIE+Standards+and+Profiles

53

54 of 59

Message Standards

PIX - The Patient Identifier Cross Referencing (PIX) Integration Profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains by transmitting patient identity information from an identity source to the Client Registry.

PMIR: The Patient Master Identity Registry (PMIR) Profile supports the creating, updating and deprecating of patient master identity information about a subject of care, as well as subscribing to changes to the patient master identity, using the HL7 FHIR standard resources and RESTful transactions.

54

I just want to quickly mention the standards that support the transactions described in the architecture. The following are the key IHE standards that support the client registry transactions. These are more fully described in the OpenHIE Architecture Specification documentation that can be found on the OpenHIE website.

PIX - The Patient Identifier Cross Referencing (PIX) Integration Profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains by:

Transmitting patient identity information from an identity source to the client registry.
Providing the ability to access the list(s) of cross-referenced patient identifiers either via a query/ response or via an update notification

PMIR: The Patient Master Identity Registry (PMIR) Profile supports the creating, updating and deprecating of patient master identity information about a subject of care, as well as subscribing to changes to the patient master identity, using the HL7 FHIR standard resources and RESTful transactions. The “patient master identity” is the dominant patient identity managed centrally among many participating organizations (a.k.a., “Golden Patient Identity”). Beyond the basic create, retrieve, update, and delete transaction set, this profile addresses important patient safety issues related to cases where there are two or more patient master identities that have been established for the same person, thus it is not clear which identity is the “true” one. There is also a risk that health data (possibly conflicting) may be associated with each identity – and these disparate data, together, may need to be reconciled before a fully and accurate “health picture” can be developed for this person.

55 of 59

References

OpenHIE Architecture Specification

OpenHIE Identity Management Community - join the community of people engaging to provide input on tools and standards and address implementation issues.

OpenHIE Community Discussion Forum - Ask questions and engage with community members through on-line discussion

OpenHIE Standards and Profiles

OpenHIE Reference Software

55

56 of 59

Bibliography - Theory

Fellegi IP, Sunter SB. (1969). A Theory for Record Linkage. Journal of the American Statistical Association, 64(328), 1183-1210.
Dunn HL. (1946) Record Linkage. Am J Public Health. 36, 1412-1416.
Newcombe HB. (1988) Handbook of Record Linkage, Methods for Health and Statistical Studies, Administration, and Business. Oxford University Press.
Newcomb HB, Kennedy JM. Axford SJ, James AP. (1959) Automatic Linkage of Vital Records. Science, 130, 954-959.
Gill, L., Methods for Automatic Record Matching and Linking and their use in National Statistics. Her Majesty’s Stationary Office, Norwich, 2001.
Porter E, Winkler W. Approximate String Comparison and its Effect on an Advanced Record Linkage System. Record Linkage Techniques--1997: Proceedings of an International Workshop and Exposition. National Academy Press, Washington DC 1999.
Public Health Informatics Institute. The unique records portfolio. Decatur, GA: Public Health Informatics Institute, 2006.

56

57 of 59

Bibliography:�Applications and Research (1)

Christen P. Febrl: A freely available record linkage system with a graphical user interface. Submitted to the Australasian Workshop on Health Data and Knowledge Management (HDKM), Wollongong, January 2008.
Potosky A, Riley G, Lubitz J, et al. Potential for Cancer Related Health Services Research Using a Linked Medicare-Tumor Registry Database. Medical Care 1993;31(8):732-748.
Whalen D, Pepitone A, Graver L, Busch JD. Linking Client Records from Substance Abuse, Mental Health and Medicaid State Agencies. SAMHSA Publication No. SMA-01-3500. Rockville, MD: Center for Substance Abuse Treatment and Center for Mental Health Services, Substance Abuse and Mental Health Services Administration, July 2000.
Liu S, Wen SW. Development of Record Linkage of Hospital Discharge Data for the Study of Neonatal Readmission. Chronic Diseases in Canada 1999; 20(2):77-81.
Pates R, Scully W, et al. Adding Value to Clinical Data by Linkage to a Public Death Registry. MedInfo 2001;10(Pt 2):1384-8

57

58 of 59

Bibliography:�Applications and Research (2)

Lynch BT, Arends WL. Selection of a surname coding procedure for the SRS record linkage system. Washington, DC: US Department of Agriculture, Sample Survey Research Branch, Research Division, 1977.
Newman T, Brown A. Use of Commercial Record Linkage Software and Vital Statistics to Identify Patient Deaths. J Am Med Inform Assoc. 1997 May-June; 4 (3): 233-237.
Schadow G, McDonald CJ Maintaining Patient Privacy in a Large Scale Multi-Institutional Clinical Case Research Network. AMIA Proceedings (2002 Submission).
Public Health Informatics Institute. (2006). The Unique Records Portfolio. Decatur, GA: Public Health Informatics Institute
Sideli R, Friedman C. Validating Patient Names in an Integrated Clinical Information System. Symposium on Computer Applications in Medical Care, Washington, DC. November 1991:588-592.
OpenHIE Standards and Profiles - Documents. OpenHIE Wiki. (n.d.). https://wiki.ohie.org/display/documents/OpenHIE+Standards+and+Profiles.

58

59 of 59

Bibliography:�Applications and Research (3)

Miller PL, Frawley SJ, Sayward FG. IMM/Scrub: a domain-specific tool for the deduplication of vaccination history records in childhood immunization registries. Computers and Biomedical Research 2000;33:126–143.
Salkowitz SM, Clyde S. De-duplication technology and practices for integrated child-health information systems. Decatur, GA: All Kids Count, Public Health Informatics Institute, 2003.
Van Den Brandt PA, Schouten LJ, Goldbohm RA, Dorant E, Hunan PMH. Development of a record linkage protocol for use in the Dutch Cancer Registry for epidemiological research. Int J Epidemiol 1990; 19:553-8.
Grannis SJ, Overhage JM, McDonald CJ. Analysis of Identifier Performance Using a Deterministic Linkage Algorithm. Proc AMIA Symp 2002:305-9.
Grannis SJ, Overhage JM, McDonald CJ. Analysis of a Probabilistic Record Linkage Technique without Human Review. In: Proceedings of American Medical Informatics Association Fall Symposium; 2003; Washington, D.C.; 2003.
Integrating the Health Care Enterprise. (2006) Patient Identifier Cross-Reference (PIX) and Patient Demographic Query (PDQ) HL7 v3 Transaction Updates. Available at: http://www.ihe.net/Technical_Framework/upload/ IHE_ITI_TF_Suppl_PIXPDQ_HL7v3_PC_2006_08_15.pdf

59