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:
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.
Last updated