What are the minimum matching criteria recommended for reliable demographic based patient matching

identity

When matching patients based on demographic data are there any recommendations on what fields should match for the patient to be the "Same Patient"?

I know the algorithms will be different for different implementations, I'm just curious if there are any best practices or recommendations around this process.

First Name
Last Name
Date of Birth
SSN
Address
City
State
Zip

etc?

Best Answer

There's this great essay (in spanish, sorry) written by Pablo Pazos, a CS Engineer from Uruguay who has been working on Healthcare IT since 2006 and has made some great contributions to the field, in which he describes an algorithm for doing this.

You can run the article through a translator, but the gist of it is that the basic info to determine a person's identity are their given and family names (both from father and mother), sex, and date of birth. Interestingly enough, he specifically excludes id numbers like SSN from his identity matching algorithms, since "any kind of identifier is NOT part of his identity" (I guess this point could be debatable, though). Also, he excludes attributes like street address, phone numbers, etc. since they aren't really related with the identity of someone, they aren't associated with "who someone actually is".

Also, he assigns different "weights" to each of the former attributes, like this:

First name: 17.5%
Middle name: 17.5%
Family name (father): 17.5%
Family name (mother): 17.5%
Sex: 10%
DOB: 20%

With the matches found on every one of these attributes, he describes a methodology to obtain a composite "concordancy match index" with which comparisons between records can be possible. Also, "partial" matches on the name attributes are possible by using algorithms like Levenshtein's distance.

Good read, IMO. Sorry it's in spanish, but I hope I was able to convey its main ideas.

Related Solutions

Sql-server – the rationale for requiring a column list when inserting into a table with identity column

If you don't specify the column list then this implicitly assumes a column list including all user insert-able columns (non identity, rowversion, computed) as below.

CREATE TABLE #T
(
C INT IDENTITY,
D INT,
E INT
)

INSERT INTO #T
VALUES (2,3)

This is far more generally useful as the most common reason for having an IDENTITY column is to allow SQL Server to manage the values.

I suppose it could imply that if there was an extra column in the insert source on an identity table that it should generate an execution plan for the explicit identity_insert case but not much benefit to this IMO.

SQL Server – Reserve Block of IDs for Bulk Insert

You can use procedure (introduced in SQL Server 2012):
sp_sequence_get_range

To use it you need to create a SEQUENCE object and use it as a default value instead of IDENTITY column.

There is an example:

CREATE SCHEMA Test ;  
GO  

CREATE SEQUENCE Test.RangeSeq  
    AS int   
    START WITH 1  
    INCREMENT BY 1  
    CACHE 10  
;

CREATE TABLE Test.ProcessEvents  
(  
    EventID int PRIMARY KEY CLUSTERED   
        DEFAULT (NEXT VALUE FOR Test.RangeSeq),  
    EventTime datetime NOT NULL DEFAULT (getdate()),  
    EventCode nvarchar(5) NOT NULL,  
    Description nvarchar(300) NULL  
) ;


DECLARE 
   @range_first_value_output sql_variant ;  

EXEC sp_sequence_get_range  
@sequence_name = N'Test.RangeSeq'  
, @range_size = 4  
, @range_first_value = @range_first_value_output OUTPUT ;

SELECT @range_first_value_output;

Documentation: sp_sequence_get_range