Overview
Accurate and efficient unique identification of patients is an essential function for a fully realized eHealth architecture. A client registry (CR) is designed to support patient identity management. The OpenHIE CR community seeks to foster innovative technology that provides accurate, reliable and stable identification and de-duplication of individuals and other entities in a variety of contexts, particularly resource-constrained settings.
Workflows
To be OHIE the system must support one or more of the OHIE workflows listed below:
A core principle of the OpenHIE architecture is to allow the various infrastructure services (such as the CR) to be interchangeable. See: OpenHIE Standards and Profiles.
Recommended Functional Requirements
Depending upon the desired use case(s), the system may support many or all of these functional features.
Configurable Entity matching - A service to assist in identifying duplicate patients
The rules for determining whether two records match each other should be configurable.(e.g., ability to use both statistical and/or rules based, etc.)
The blocking strategy for loading potential matches before the matching rules are applied should be configurable.
Any configurable component should have an interface so that advanced users can write their own implementation from scratch if desired.
Any interface should have at least one default implementation.
The default implementation should be flexible and configurable so that non-programmers can adjust it to meet their needs.
To the extent possible, CR system configuration information should be managed using consistent and easy to access methods, such as a database, properties files, or XML files).
It should allow “wizard-based” or “guided” setup of matching rules
Patient Linking and De-duplication
The system should implement accurate and efficient patient linking and de-duplication methods.
It should provide an easy to use and intuitive way to see merge/linkage operations
It should allow an easy to use and intuitive way of manually accepting or rejecting merge suggestions, with the ability to choose fields from either record to be merged
Configure and monitor inbound/outbound transactions.
The system must have the capacity to record receipt and transmission of transactions.
Synchronize client IDs with a SHR. (Support patient-level clinical data OHIE workflow)
UI to search patients, manually edit (e.g., create, update, merge, split, and deprecate)
UI to review and manually adjudicate uncertain (“potential”) matches, and override incorrect matches.
Configurable Attributes -
The attributes that form a patient record and are used for matching should be configurable.
The implementation can include an example/default patient schema.
It should be easy to add attributes to the schema.
It should also be easy to remove attributes from the default model (or start over from scratch).
Error Management: Ensure that error handling comprehensively captures and logs all related exceptions, and to the extent possible, shows relationships between exceptions.
Logging: Logging should be consistent; it should be easy to find information in the log.
Privacy/Security: The system should have functions including user management and access controls.
Pediatric Option: it is mandatory for an OpenHIE-conformant CR to support the PIX “Pediatric Option”
Scalability
Scales to millions of patients: Client registries are increasingly expected to support unique at edification of large patient populations. The CR design must support efficient operation (sub-second response time to identity queries) when managing millions of patients.
Support of OpenHIE Non-functional Requirements
An OpenHIE component should consider the following OpenHIE Non-Functional Requirements - Draft