Client Registry (CR)
The identity of an individual who receives health services is crucial to enabling health care record sharing across institutions and systems. Yet, sharing health care records can be a challenge in a complex environment where there are multiple systems across multiple health care institutions and each institution and/or system has a different way to identify their clients. Even in environments where citizens are assigned national identification cards, there is a need to ensure the unique identity of an individual among the myriad fragmented information systems that collectively represent a person’s electronic health record. The Client Registry is designed to assist in uniquely identifying individuals who receive health care services by:
Maintaining a central registry of all patients and their demographics and assigning a unique identifier to each patient.
Linking patient registration entries that result due to changes in patient demographics (patient moved to another location), data entry errors during patient registration, or missing demographic information.
Enabling health care workers to identify facilities at which a patient has received care.
See also Non-Functional Requirements.
OpenHIE CR Workflow Requirements
A core principle of the OpenHIE architecture is to allow the various infrastructure services (such as the CR) to be interchangeable. To support this, the OpenHIE Standards and Profiles used by the Client Registry are outlined in the workflows below. To be an OHIE CR component, the CR application must be able to support the OHIE workflows listed below. Implementations may support only the workflows needed to support their use case:
# | CR Workflows (Described in detail in the later part of this document) | Recommendation/Requirement |
CRWF-1 | A CR shall support the “Create patient demographic record workflow” | Requirement |
CRWF-2 | A CR shall support the “Update patient demographic record workflow” | Requirement |
CRWF-3 | A CR shall support the “Query patient demographic records by identifier workflow” | Requirement |
CRWF-4 | A CR shall support the “Query patient demographic records by demographics workflow” | Requirement |
OpenHIE CR Functional Requirements
The following are typical features of a client registry, or master patient index. Depending upon the desired use case(s), the system may support many or all of these functional features.
# | CR Functional Requirement | Recommendation/ Requirement |
CRF-1 | The system should support configurable entity matching, a service to assist in identifying duplicate patients. a. 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.). b. The blocking strategy for loading potential matches before the matching rules are applied should be configurable. c. Any configurable component should have an interface so that advanced users can write their own implementation from scratch if desired. d. Any interface should have at least one default implementation. e. The default implementation should be flexible and configurable so that non-programmers can adjust it to meet their needs. f. 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). g. It should allow “wizard-based” or “guided” setup of matching rules. | Recommended |
CRF-2 | The system shall support patient linking and de-duplication. a. The system shall implement accurate and efficient patient linking and de-duplication methods. b. It shall provide an easy to use and intuitive way to see merge/linkage operations, c. 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. | Required |
CRF-3 | The system should support the ability to track and monitor inbound/outbound transactions. a. The system must have the capacity to record receipt and transmission of transactions. | Recommended |
CRF-4 | The system should support synchronization of client IDs with a Shared Health Record (SHR). | Recommended |
CRF-5 | The system should support a UI to review and manually adjudicate uncertain (“potential”) matches, and override incorrect matches. | Recommended |
CRF-6 | The system should support configurable attributes including: a. The attributes that form a patient record and are used for matching should be configurable. b. The implementation can include an example/default patient schema. c. It should be easy to add attributes to the schema. d. It should also be easy to remove attributes from the default model (or start over from scratch). | Recommended |
CRF-7 | The system should support error management a. Ensure that error handling comprehensively captures and logs all related exceptions, and to the extent possible, shows relationships between exceptions. | Recommended |
CRF-8 | The system shall manage a full audit log of changes to data as well as configurations as well as users. | Required |
CRF-9 | Privacy/Security: The system should have functions including user management and access controls. | Recommended |
CRF-10 | The system should be able to persist the parent/child relationship, birth order, and multi-birth indicator. | Recommended |
Last updated