| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 2.0.2 E25246-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 2.0.2 E25246-02 |
|
|
PDF · Mobi · ePub |
This chapter provides an introduction to the Oracle Healthcare Master Person Index (OHMPI), and the features of its applications, including the function of the Master Index Data Manager (MIDM). It also provides conceptual information about MIDM object profiles.
This chapter includes the following sections:
The Master Index Data Manager is your primary tool to view and maintain the data stored in the master person index database and cross-referenced by a master person index application. It is a web-based interface that allows you to access, monitor, and maintain the data stored by the master person index applications you create using Oracle Healthcare Master Person Index. The MIDM provides the ability to search for, add, update, delete, deactivate, reactivate, merge, unmerge, and compare object profiles. You can also view and correct potential duplicate profiles, view transaction histories, view source records, view patient summary information, view an audit log, and print reports.
Oracle Healthcare Master Person Index provides a flexible framework, which allows you to create matching and indexing applications called master person index applications. It is an application building tool to help you design, configure, and create a master person index application that will uniquely identify and cross-reference the business objects stored in your system databases. Business objects can be any type of entity for which you store information, such as patients, doctors, hospitals, healthcare facilities, pharmacies, and so on. Oracle Healthcare Master Person Index allows you to define the data structure of the business objects to be stored and cross-referenced. In addition, you define the logic that determines how data is updated, standardized, weighted, and matched in the master person index database.
The following sections provide additional information about Oracle Healthcare Master Person Index, the master person index applications created by Oracle Healthcare Master Person Index, and the Master Index Data Manager (MIDM).
The applications created by Oracle Healthcare Master Person Index are enterprise-wide master person index applications that maintain the most current information about the objects in your business enterprise. A master person index application creates a single, consistent view of all object data by providing an automatic, common identification process regardless of the location or system from which the data originates. Object profiles from various locations are cross-referenced using an enterprise-wide unique identifier (EUID) assigned to each profile by the master person index application. By creating EUIDs, a master person index application can identify many types of participants, such as customers, employees, contacts, and so on.
The identification and general information for all objects is centralized in one shared index. A master person index application is designed specifically to support scattered business locations and disparate information systems across an enterprise, as well as various applications from multiple vendors. Maintaining a centralized database for multiple systems enables a master person index application to integrate data throughout the enterprise while allowing local systems to continue operating independently. A master person index application makes it easy to find information that was previously scattered among multiple systems.
The components of the master person index applications you create are highly configurable, allowing each master person index application to be customized for your specific data processing needs. Primary features of a master person index application include the following:
Centralized Information - A master person index application maintains a centralized database, enabling the integration of data records throughout the enterprise while allowing local systems to continue operating independently. The index stores copies of local source records and the single best record (SBR), which represents the most accurate and complete data for each object. This database is the central location of all object information and identifiers, and is accessible throughout the enterprise. Records from various systems are cross-referenced using the EUID assigned by a master person index application to each object profile.
Configurability - Before deploying a master person index application, you can customize the components and processing capabilities of the system. The configurable components include:
The types of objects to index
The types of data stored
The standardization and match engines to use
Matching, standardization, and phonetic conversion rules
Survivorship and weighting rules for determining the SBR
The types of queries available
How queries are blocked, or grouped, for match processing
MIDM appearance
Searches available to the MIDM
Local ID validation rules
You can deploy MIDM on single or multiple machines using the configurability feature. Deploying MIDM on multiple machines helps isolate the web layer from the business layer thereby making the application more scalable.
Cross-referencing - A master person index application serves as a global cross-reference, matching profiles across disparate source systems and simplifying the process of sharing data between systems. A master person index application uses the local identifiers assigned by your existing systems as a reference, allowing you to maintain your current systems and practices.
Data Cleansing - A master person index application uses configurable matching algorithm logic to uniquely identify object profiles and to identify duplicate and potential duplicate profiles. A master person index application provides the ability to easily merge or resolve duplicates, and can be configured to automatically match profiles that are found to be duplicates of one another.
Data Updates - A master person index application provides the ability to add, update, deactivate, merge, and delete data in the database tables through messages received from external systems or the MIDM. Messages received from external systems and the MIDM are checked for potential duplicates during processing.
Updates to External Systems - The master person index application can publish updated information to external systems, provided the external systems can accept incoming messages. This is handled through a JMS Topic to which a master person index application publishes XML messages that contain the updates.
Identification - A master person index application employs configurable probabilistic matching technology. This technology uses a matching algorithm to formulate an effective statistical measure of how closely profiles match. Using a state-of-the-art algorithm in real-time mode and establishing a common method of locating profiles, a master person index application consistently and precisely identifies objects within an enterprise.
Matching Algorithm - A master person index application is designed to use the OHMPI Match Engine or a custom matching algorithm to provide a matching probability weight between object profiles. You define matching thresholds, which control how potential duplicates and automatic merges are determined.
Unique Identifier - A master person index application assigns an enterprise-wide unique identifier (EUID) to each object added to the database. The index uses the EUID to cross-reference the local IDs assigned to each object by the various computer systems throughout the enterprise.
Security - A master person index application provides secure access to the patient information. It also provides restricted access to patient records by masking and unmasking their sensitive data. This feature is configurable.
While a master person index application cleanses data automatically as it is entered through external system messages or through the MIDM, there are instances where it cannot be determined automatically whether two object profiles truly match one another. In these cases, manual review through the MIDM is needed to verify the status of the two profiles and then to possibly join two potential duplicate profiles or separate two profiles that were automatically joined. The MIDM provides additional functions to help you maintain the data you store.
Using the MIDM, you can perform the following activities.
View an Object's History - The system provides a complete transaction history of each object profile by recording all changes to each object's data. This allows you to view before and after images of a profile for each change made. The table also records the user ID of the person who made the changes. This history is maintained for both the local source records and the SBR.
Search for Object Profiles - Using the MIDM, you can search for specific objects or sets of objects. The MIDM allows you to perform different types of searches using different combinations of data elements and returns a list of potential matches to your search criteria. For certain searches, the results are assigned a matching weight that indicates the probability of a match.
Maintain Object Data - The MIDM supports all the necessary features for maintaining object profiles. It allows you to add new profiles; view, update, delete, deactivate, or reactivate existing profiles; and compare profiles for similarities and differences. You can also view each local source record associated with an SBR.
Compare Object Data - The MIDM allows you to compare two or more object profiles in a side-by-side or tabular comparison so you can evaluate their differences or similarities. You can also compare different objects within one object profile in the same comparison view. For example, you can compare the profile's SBR with a record from System A and you can compare a profile's record from System A with its record from System B.
View and Resolve Potential Duplicates - The catch phrase here is data deduplication, which improves storage utilization by identifying and eliminating redundant data. Using algorithm matching logic, a master person index application has the ability to identify potential duplicate profiles, and the MIDM provides the ability to manually correct the duplicate profiles. Profiles that are potential duplicates can be viewed online in a side-by-side or tabular comparison. Potential duplication is resolved by either merging the profiles in question or removing their potential duplicate flags.
Merge and Unmerge Profiles - You can compare potential duplicate profiles and then merge the profiles if you find them to be the actual duplicates of one another. Using the merge feature, you can determine which profile to retain as the active profile. The MIDM also allows you to merge source records between object profiles and to specify which information from each source record to preserve in the resulting profile. If two object profiles or source records are merged in error, you can unmerge them, returning the information to the original records. You can also view a history of merges for a profile by viewing the transactions page for the specified EUID or Local ID for the SBR. You can only unmerge the last merged transaction from the profiles.
Audit Log - The system administrator can specify that a log be maintained for each instance of the object data that is accessed from the MIDM. This log provides information such as the ID of the user who accessed the data, the type of action that was performed against the data, and the date and time of access.
Security - Security is provided through the application server (WebLogic or GlassFish) and includes basic access to the database through user login IDs and passwords, as well as access to specific functions and actions of a master person index application. Access can be restricted by functions, actions within functions, data element, and user ID.
The information about an object in a master person index application is stored in an object profile. The profile includes information from all of the source records for that object and also includes a record that contains the best information about the object according to the master person index application.
The following sections describe object profiles and their components:
An object profile, also known as an enterprise record, is a set of information that describes characteristics of an individual object in the master person index application. An object profile includes information from one or more source systems. The information can be divided up into child objects, which hold additional information about an object, such as address information, telephone information, or alias names.
A profile contains two types of records:
Source Records - A source record, also known as a system record, is a set of information from an external system that shares data with a master person index application. A profile might contain several source records.
Single Best Record - The single best record (SBR) is a set of information derived from the best information from each source record in an object profile (as determined by the survivor calculator). Each object profile has only one SBR.
Source records are different from the SBR in that each source record contains a system and local ID pair and only contains data from a specific system. The information in the source records of an object profile is used to determine the best values for the SBR in that profile. If an object profile only contains one source record, the SBR will be identical to that source record. However, if an object profile contains multiple source records, the SBR may be identical to one source record but will more likely include a combination of information from all source records. Certain actions against a source record will cause the SBR to be changed, such as updating, deleting, deactivating, merging, and unmerging a source record. Each active object profile must have at least one active source record. If all source records in a profile are deactivated, then the entire profile will also be deactivated.
The single best record (SBR) for an object profile is made up of a combination of information from all active source records associated with that object profile. The SBR represents the information that is determined by the master person index application to be the most reliable and current of all source records in an object profile. The SBR is dynamic and is recalculated each time an update is made to an associated source record, a merge or an unmerge affects the object profile, or a source record in the profile is deactivated or reactivated. You can use the overwrite capability of the MIDM to update the SBR directly or you can update a source record and allow the survivor calculator to determine how to update the SBR (for more information, see Survivor Calculator).
You can override the survivor calculator by specifying values for the SBR in two ways. You can use the overwrite capability to update a field, and that field remains locked and cannot be updated by changes to source records until the field is unlocked. You can also link a field in the SBR to the same field in one of the profile's source systems, and that SBR field will always contain the same value as the source system until the link is removed. For more information about the Overwrites and linked fields, see Linking Field Values in the SBR.
The survivor calculator determines which information from each source record in an object profile is stored in the SBR for that profile. The calculator uses information defined by the system administrator to calculate the SBR. By default, the survivor calculator uses a weighted strategy for most fields, using the relative reliability assigned to each system in combination with the reliability given to the most recently updated value.
For some fields, such as alias and auxiliary IDs, a union strategy is typically used. This means that all unique alias names and auxiliary IDs from all systems are included in the SBR. For detailed information about the survivor calculator and configuring the survival strategy, see Oracle Healthcare Master Person Index Configuration Reference and Oracle Healthcare Master Person Index Configuration Guide.
In a master person index application, each source record and SBR in an object profile contains a set of sub-objects that store different types of information about the object. Generally, a record contains a parent object and several child objects. A record can have only one parent object, but can have multiple child objects and multiple instances of each child object with each instance being identified by a unique field. For example, in a master person index a record can only contain one person name and social security number (contained in the parent object), but could have multiple addresses, telephone numbers, and aliases (contained in child objects). Typically each address must be of a different type, such as a home address, billing address, or mailing address.
Each object profile in a master person index application is assigned a unique identification number in addition to the local IDs assigned by individual systems. Each object has one unique identification number throughout your organization and a unique identification number within each system with which they are registered.
Every object profile in the master person index system is assigned an enterprise-wide unique identification number. This number is the same for that object regardless of the system from which the object information originates. This number is called the enterprise-wide unique identifier (EUID) and is used to cross-reference object profiles in order to accurately identify the objects throughout your organization.
A local ID is a unique local identification number that is assigned to an object in each system at which it is registered. These numbers are assigned using a numbering system unique to each local system, and are used internally by the systems to identify each object. A master person index application uses an object's EUID to cross-reference its local IDs in different systems. Note that the name of the Local ID field is configurable and might be different for your implementation.
An auxiliary ID is an identification code that does not necessarily uniquely identify a single object within the database, but might identify a group of objects. For example, if a family shares the same account or insurance policy, every family member would have the same identification code for that account or policy.
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
