OpenHIE Entity Matching Service

Purpose 

The purpose of the entity matching service is to enable matching in a single list of patients, health workers, facilities or other entities or to find potential matches between two lists of the same entities.  

Potential Use Cases

We envision the following potential use cases:  

1. Ensuring the the entity doesn't exist when entering a new instance of the entity

2. Duplicate checking during bulk imports.  

3. Analysis of potential duplicates in an existing data set.  

4. Mapping one data set of entities to their corresponding value in another data set. 

Potential Implementations 

Depending upon the use case, we envision that there might be a spectrum of implementation options.  We expect to learn from the first implementations and refine the use patterns based upon experience.  For now, we imagine the following types of architectural implementations:  

1. Tight coupling - A tightly coupled implementation might be one where the matching service software library is incorporated into the architecture component. 

2. Medium - This type of implementation could be one where the service interacts directly with the architecture component's data source.  

3. Loose - This type of service may load data into the service's data base and analyze the data from there.    

FHIR Reference

http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9685&start=0

High Level Overview of Mapping Service Components

Sample URL: 

https://testmap.ohie.org/registry/fhir/Location/$match

Sample Request:

<Parameters xmlns="http://hl7.org/fhir"> <parameter> <name value="location"/> <resource> <Location xmlns="http://hl7.org/fhir"> <contained> <Location xmlns="http://hl7.org/fhir"> <id value="1"/> <identifier> <value value="a.bc.1.sample"/> </identifier> <name value="simple health"/> </Location> </contained> <identifier> <value value="117"/> </identifier> <name value="simple clinic"/> <position> <longitude value="10"/> <latitude value="100"/> </position> <partOf> <reference value="#1"/> </partOf> </Location> </resource> </parameter> <parameter> <name value="count"/> <valueInteger value="5"/> </parameter> </Parameters>

Sample Response:

<Bundle xmlns="http://hl7.org/fhir"> <entry> <resource> <Location xmlns="http://hl7.org/fhir"> <id value="1000010"/> <contained> <Location xmlns="http://hl7.org/fhir"> <id value="con31"/> <identifier> <value value="A.BC.1.SAMPLE"/> </identifier> <name value="SAMPLE HEALTH"/> </Location> </contained> <extension url="http://ohie.org/fhir/StructureDefinition/datim-mechid"> <valueString value="1111"/> </extension> <identifier> <value value="117"/> </identifier> <name value="SIMPLE CLINIC"/> <position> <longitude value="10.0"/> <latitude value="100.0"/> </position> <partOf> <reference value="#con31"/> </partOf> </Location> </resource> <search> <score value="0.99762179871785583440413347489084117114543914794921875"/> </search> </entry> </Bundle>

Matching Engine Source Code:

https://tools.regenstrief.org/stash/users/amartin/repos/registry/browse

Interfaces

Different interfaces will be created to instantiate different use cases.  

Matching Algorithms that can be used - Shaun Grannis Andrew Martin - please advise here.  

Questions and Answers

Q:  Is blocking used?  

A:  The service uses coarse blocking (handled within a database query) and fine grain matching (handled in Java). 

Q:  Case sensitivity

A:  It’s easy to do case-insensitive comparisons in Java (and I’ve been making improvements in that area).  It’s also easy to write a case-insenstive SQL query:

select * from organisationunit where upper(name)=upper(?)