Client Registries and OpenCR

Data Use Community Presentation

Richard Stanley, Senior Product Manager

Outline

• Problem statement
• Record linkage as the solution
• Client registries as platforms for record linkage
• Use cases
• The Open Client Registry (OpenCR)
• Implementation

Problem Statement

What is the problem?

​

• Patient data is in different systems which are unlinked, duplicated and indexed differently.

​

• This makes it difficult to use clinical data for care coordination, reporting, monitoring, surveillance, and research.

Example

Indicator Reporting -- Interruptions in HIV Treatment

​

• Silent transfers
• Patients receive HIV care in one setting, but move to another setting.

​

• This results in overestimates for interruption in treatment
• Such patients are assumed to experience an interruption in treatment when actually they are unaccounted-for transfers.

​

​

​

Solution

What is the solution?

• Record linkage -- the process of linking patient identities across systems

​

How is it done?

• Sophisticated matching methods using demographic identifiers to identify patients across systems.

​

Where does record linkage happen?

• In a Client Registry -- an authoritative index of patients across information systems.

Client Registries

What is a Registry?

• Registries are authoritative, standardized, complete, and up-to-date lists.

​

• Registries enable the large scale exchange of health information, whether they be lists of facilities, health workers, clients (patients) or other entities.

What is a Client Registry?

• Also called an Enterprise Master Patient Index (EMPI)

​

• Client (patient) registries perform record linkage based on demographic (not clinical) data.

​

• Unique IDs may enable a shared health record care coordination, reporting, monitoring, surveillance, and research.

​

​

What is in a Client Registry?

What can be stored

• Patient, system identifiers
• Demographic information
• Date of birth, place of birth
• Names
• Gender
• Addresses
• Marital Status
• Telephone / email addresses
• Multiple birth status/order
• Death status / date
• Relationships
• Mother/father/next of kin

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

Use Cases

Example

Indicator Reporting -- Interruptions in HIV Treatment

​

• Silent transfers
• Patients receive HIV care in one setting, but move to another setting.

​

• This results in overestimates for interruption in treatment
• Such patients are assumed to experience an interruption in treatment when actually they are unaccounted-for transfers.

​

​

​

ART Clinic 2

ART Clinic 1

Hospital

ID #456

​

ID #2001

​

ID #40393

​

Without Record Linkage

March visit to ART Clinic 2

January visit to ART Clinic 1

July visit to District Hospital

ART Clinic 2

ART Clinic 1

Hospital

ID #456

​

ID #2001

​

ID #40393

​

Without Record Linkage

March visit to ART Clinic 2

January visit to ART Clinic 1

July visit to District Hospital

District Data Manager

Sees duplicate patients in the reporting system

ART Clinic 2

ART Clinic 1

Hospital

ID #456

Unique ID: ek76382

ID #2001

Unique ID: ek76382

ID #40393

Unique ID: ek76382

With Record Linkage

March visit to ART Clinic 2

January visit to ART Clinic 1

July visit to District Hospital

Client Registry

​

​

Unique ID: ek76382

ART Clinic 1 ART Clinic 2 Hospital

ID #456 ID#2001 ID #40393

ART Clinic 2

ART Clinic 1

Hospital

ID #456

Unique ID: ek76382

ID #2001

Unique ID: ek76382

ID #40393

Unique ID: ek76382

With Record Linkage

March visit to ART Clinic 2

January visit to ART Clinic 1

July visit to District Hospital

District Data Manager

Sees a Single Person

Linked ID ek76382

​

Use Case: HIV Reporting

HIV Reporting Scenario

• One patient can go to multiple facilities or service providers

​

How it works

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

​

Value add

• Deduplication of records and more accurate indicators on interruption in treatment.

Use Case: Patient Safety

Patient Safety Scenario

• One patient can go to multiple facilities or service providers

How it works

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

​

Value add

• Patient safety. Clinicians can view a comprehensive record of care history.

Use Case: Viral Load Tests

Viral Load Tests Scenario

• A laboratory information system contains records of viral load tests. Multiple results for the same patients are stored within the system.

​

How it works

• The Client Registry links patients based on a unique identifier.
• The unique ID is used to combine test results for the same patient.

​

Value add

• Data managers can deduplicate records and more accurately track viral load over time and place.

Open Client Registry

OpenCR

OpenCR is Available Today

Available today at https://openclientregistry.org

Multiple rounds of investment

Open standards, open source community

• Built for scale
• Uses the reference HAPI FHIR server as the backend,
• Popular ElasticSearch engine for matching
• Built on common standards
• Works with proprietary and open source systems
• Standalone
• Independent of vendor-specific platforms/EMRs
• FHIR datastore, not custom database models

​

​

OpenCR Key Features

OpenCR Additional Features

OpenCR is a Global Good

• Standalone, open source, and standards-based.
• Leverages major open source tools.
• Lightweight
• 6,500 lines of code in core app.
• Hostable in-country.
• 900 lines of code for packaging (CentOS, Docker)
• 90 pages of documentation
• 25 algorithm variations; deterministic and probabilistic matching
• UI
• Human adjudication and auditing decision rules
• OpenMRS modules: Ease of use for frontline workers.

Administrative Interface

Patient Record View

Patient History

​

​

Action Required

Move Records between IDs

Implementation

Lessons Learnt

Constraints

Solutions

• Many different facility, mobile, community, lab info systems and vendors, disuse of systems.
• Networking, power: EMRs are often not networked and if so, limited network connectivity, electricity.
• Non real-time data: Data may be entered end of the day or another periodic time.

• Consider reporting use cases before care continuity use cases.
• Lightweight solution that adaptable to any situation
• Incremental deployment. Rollout to regional or a vendor-centric network of EMRs
• Use any electronic client data. Don’t rely entirely on fully developed systems.
• Capable of batch, non-real time. Asynchronous, not synchronous.

Client Registry Governance and IT

Governance

• Compliance, laws, mandate
• Patient privacy (PII): Establish a minimum data set
• Data locality: Client registries are an in-country service
• Scale and scaling up: Across which providers, clinics, and implementers

Data and IT

• User roles and responsibilities: Who manages a CR?
• Data access: Which trusted systems can use a CR?
• Data use: What are trusted systems allowed to do?
• Data provenance
• Security: Node and user authentication, authorization
• Auditability and traceability

How to Implement Record Linkage

• Decide on a minimum data set (MDS)
• Learn decision rules best practices
• Test and tweak decision rules with the MDS
• Requires expertise to determine thresholds
• Establish a feedback mechanism with POS system owners on poor matches.

​

More at:

openclientregistry.org

​

Contact:

rstanley@intrahealth.org

Additional Slides

Patient Record Linkage

Goal: Provide Unique Identifiers

Overview of Patient Record Linkage

• Record linkage is a series of programmable decisions (algorithms) that decide whether different records are the same individual

​

• There are no perfect decision rules

​

• The optimal decision will depend on the data at hand and tolerance for imperfection

Steps in Record Linkage

Record Linkage Process

Database A

Pre-processing

Blocking

Comparison

Classification

Clerical Review

Non Matches

Matches

Potential Matches

Evaluation

Pre-processing: cleaning and segmenting fields into well-defined and consistent output variables

​

​

​

Comparison: identifying the similarity between two records seeking comparison vectors

Evaluation: comparing match results with the known ground truth or gold standard

Indexing/blocking: the strategy that reduces the number of paris of records to be considered

(Christen et al. 2002, 2004, 2012)

adapted by Mayer Antoine

Record Pairs

​

Record Pairs

​

Record Pairs

​

Record Pairs

​

Records

​

Classification: based on comparison results, records are found to be matches, non-matches, or potential matches

Evaluation and Data

Evaluation

• How do we know that record linkage is working as expected?
• Easily quantified into a confusion matrix
• False positives, false negatives, true positives, true negatives

​

Data

• Depersonalized or obscured real data
• Generate fake data with known duplicates, for example: https://github.com/mayerantoine/duplicategenerator

Classification & Evaluation

Source. McFarlane, T. D., Dixon, B. E., & Grannis, S. J. (2016). Client registries: identifying and linking patients. In Health Information Exchange (pp. 163-182). Academic Press.

Match Quality: Confusion Matrix

Precision: Correct matches (TP) among matches made by algorithm (TP+FP)

Matched?

Should match?

Recall: Correct matches (TP) among all true matches in the set (TP+FN)

OpenCR Technical

Functionality of OpenCR

​

​

1. Patient presents at Clinic
2. Registrar registers Patient in EHR
3. EHR submits Patient to OpenCR
4. OpenCR searches ElasticSearch for matches based on configured decision rules
5. ElasticSearch returns results
6. OpenCR creates or updates FHIR Patient resources and Audit events
7. FHIR server returns results
8. OpenCR returns Client Registry Unique IDs

Architecture

OpenCR Record Linkage

Database A

Pre-processing

Blocking

Comparison

Classification

Clerical Review

Pre-processing:

Point of Service (POS) system sends pre-processed records to the OpenCR API

​

​

​

Comparison:

ElasticSearch identifies the similarity between two records seeking comparison vectors

Indexing/blocking: OpenCR API queries ElasticSearch with user-configured search criteria

Record Pairs

​

Record Pairs

​

Records

​

Clerical Review:

A GUI allows users to browse and break matches

Classification:

ElasticSearch returns potential matches. OpenCR creates or updates links to matches and assigns or updates a CRUID.

CRUID