Tools for Designing a Master Patient Index and Other Registries

Executive Summary

This article outlines a list of tools for designing a Master Patient Index (MPI) (also known as a client registry) or other registries as part of an interoperable health information exchange. It incorporates examples of previously implemented projects in a variety of jurisdictions which can be used in determining requirements and producing specifications for an organization's own client registry. 

Companion Articles

A Guide to Planning a Health Information Exchange (HIE)

Implementing a Master Patient Index 


What is an MPI?

A Master Patient Index (MPI)—also referred to as a patient registry or client registry— is an electronic database that holds demographic information on every patient who receives healthcare services. The MPI aims to accurately match and link records by uniquely identifying individuals to maintain consistent and accurate information about each patient. This is accomplished by storing information such as name, date of birth, gender, etc., and assigning everyone a unique identifier. This allows personal healthcare records to be shared with different hospitals, rehab facilities, pharmacies or other healthcare providers that may need access to one’s medical records in a secure, timely and cost-effective manner. 

When constructing an MPI there are business requirements, use cases, interoperability standards and workflow documents, functional and non-functional requirements, integration test cases and load and performance test cases that must be considered. 

Business Requirements

Example tools for business requirements:


Use Cases

  • RHEA Rwanda Project (Key Use Cases for the POC applications using the HIX layer outlined on page 16)
  • Massachusetts eHealth Institute has developed an online toolkit that aids in the design and structure of a use case for a Health Information Exchange.


Interoperability standards and workflows documents: 

The following examples come from the Open EMPI Entity Edition Documentation and can be used to help draft required documents:


Functional requirements

The tools listed below are good examples of MPI functional requirements:


Non-functional requirements

Examples include:


Test Cases


Defining the actors and the supported transactions they are involved in

Load and Performance:

OpenEMPI's load testing method and results can be used as a reference.