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.

Standards

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. 

Workflows

To be OHIE  the system must support one or more of the OHIE workflows listed below:

1. Create patient demographic record workflow

2. Update patient demographic record workflow

3. Query patient demographic records by identifier workflow

4. Query patient demographic records by demographics workflow

Recommended Functional Requirements

Depending upon the desired use case(s), the system may support many or all of these functional features.  

1. Configurable Entity matching - A service to assist in identifying duplicate patients

1. 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.)

2. The blocking strategy for loading potential matches before the matching rules are applied should be configurable.

3. Any configurable component should have an interface so that advanced users can write their own implementation from scratch if desired.

4. Any interface should have at least one default implementation.

5. The default implementation should be flexible and configurable so that non-programmers can adjust it to meet their needs.

6. 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).

2. Patient Linking and De-duplication

1. The system should implement accurate and efficient patient linking and de-duplication methods.

3. Configure and monitor inbound/outbound transactions.

1. The system must have the capacity to record receipt and transmission of transactions.

4. Synchronize client IDs with a SHR. (Support patient-level clinical data OHIE workflow)

5. UI to search patients, manually edit (e.g., create, update, merge, split, and deprecate)

6. UI to review and manually adjudicate uncertain (“potential”) matches, and override incorrect matches.

7. Configurable Attributes -

1. The attributes that form a patient record and are used for matching should be configurable.

2. The implementation can include an example/default patient schema.

3. It should be easy to add attributes to the schema.

4. It should also be easy to remove attributes from the default model (or start over from scratch).

8. Error Management:  Ensure that error handling comprehensively captures and logs all related exceptions, and to the extent possible, shows relationships between exceptions.

9. Logging: Logging should be consistent; it should be easy to find information in the log.

10. Privacy/Security: The system should have functions including user management and access controls.

11. Pediatric Option: it is mandatory for an OpenHIE-conformant CR to support the PIX “Pediatric Option”

Additional levels of support

The above forms the base standards that an OpenHIE SHR must support. A number of those standards contain many different profiles that a SHR implementation may choose to support for a variety of use cases. OpenHIE SHRs may be built incrementally to support additional profiles. These different categories of support have been broken down into different phases. These phases are listed below:

SHR Level 1 - (at least one content profile + query for existing data)

A phase 1 OpenHIE SHR must implement the following:

• XDS.b's provide and register document, stored query and retrieve document transactions

• At least one of the Patient Care Coordination CDA content profiles which profile the CDA Continuity of Care Document (CCD) specification.

• The Query for Existing Data (QED) profile

SHR Level 2 - (all PCC content profiles + query for existing data + referrals)

A phase 2 OpenHIE SHR must implement the following:

• XDS.b's provide and register document, stored query and retrieve document transactions

• ALL of the Patient Care Coordination CDA content profiles which profile the CDA Continuity of Care Document (CCD) specification.

• The Emergency Department Referral (EDR) PCC profile which supports referrals

• The Query for Existing Data (QED) profile

SHR Level 3 - (clinical documents + query for existing data + referrals + some form of data export - [perhaps lab and drug profiles])

A phase 3 OpenHIE SHR must implement the following:

• XDS.b's provide and register document, stored query and retrieve document transactions
• ALL of the Patient Care Coordination CDA content profiles which profile the CDA Continuity of Care Document (CCD) specification.

• The Emergency Department Referral (EDR) PCC profile which supports referrals

• The Query for Existing Data (QED) profile

• A to-be-determined mechanism to export data for reporting purposes