| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 3.0 E62301-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 3.0 E62301-01 |
|
|
PDF · Mobi · ePub |
This chapter provides an introduction to OHMPI and its features, including the function of the MIDM. It also provides conceptual information about MIDM object profiles.
This chapter includes the following sections:
The MIDM 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 lets you access, monitor, and maintain the data stored by the master person index applications you create using OHMPI. You can use MIDM to search 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.
OHMPI provides a flexible framework, which lets you create matching and indexing applications called master person index applications. It is an application building tool to design, configure, and create a master person index application that uniquely identifies 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. OHMPI lets you 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 OHMPI, the master person index applications created by OHMPI, and the MIDM.
The applications created by OHMPI 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, disparate information systems across an enterprise, and 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 are previously scattered among multiple systems.
The components of the master person index applications you create are configurable, letting customization of each master person index application 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 letting local systems 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:
Types of objects to index
Types of data stored
Standardization and match engines to use
Matching, standardization, and phonetic conversion rules
Survivorship and weighting rules for determining the SBR
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. When you deploy MIDM on multiple machines, it isolates the web layer from the business layer. This makes 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 that lets you maintain your current systems and practices.
Data Cleansing - A master person index application uses configurable matching algorithm logic to uniquely identify object profiles, and duplicate and potential duplicate profiles. You can use master person index application 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 the 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 uses the OHMPI match engine or a custom matching algorithm to provide a matching probability weight between object profiles. You can 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 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, manually review through the MIDM to verify the status of two profiles, and join two potential duplicate profiles or separate two profiles that are automatically joined. The MIDM provides additional functions to 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 lets you 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 local source records and SBR.
Search for Object Profiles: Using the MIDM, you can search for specific objects or set of objects. The MIDM lets you perform different types of search using different combinations of data elements, which 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 necessary features for maintaining object profiles. It lets you 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 lets you compare two or more object profiles in a side-by-side or tabular comparison to 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 SBR of a profile with a record from System A and compare the record of a profile from System A with its record from System B.
View and Resolve Potential Duplicates: The data deduplication improves storage utilization by identifying and eliminating redundant data. Using algorithm matching logic, a master person index application identifies potential duplicate profiles, and the MIDM manually corrects 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 merge duplicate profiles. Using the merge feature, you can determine the profile to be retained as the active profile. The MIDM also lets you merge source records between object profiles and specify the information to be preserved from each source record in the resulting profile. If two object profiles or source records are merged in error, you can unmerge them. You can also view the 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 to maintain a log 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 is performed against the data, and the date and time of access.
Security: Security is provided through the application server, which includes basic access to the database through user login IDs and passwords, and 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 source records for that object and 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 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 - 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 may contain several source records.
Single Best Record -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 which 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 determines the best values for the SBR in that profile. If an object profile only contains one source record, the SBR is identical to that source record. However, if an object profile contains multiple source records, the SBR may be identical to one source record but includes a combination of information from all source records. Certain actions (such as, updating, deleting, deactivating, merging, and unmerging a source record) against a source record changes the SBR. Each active object profile must have at least one active source record. If all source records in a profile are deactivated, the entire profile is deactivated.
The SBR for an object profile is 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 update a source record, and let survivor calculator 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 the following ways:
Use the overwrite capability to update a field that remains locked, and cannot be updated by changing the source records until the field is unlocked.
Link a field in the SBR to the same field in one of the profile's source systems, and that SBR field contains the same value as the source system until the link is removed.
For more information on 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 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 can have multiple addresses, telephone numbers, and aliases (contained in child objects). Each address must be 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 and 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 a EUID number. This number is the same for that object regardless of the system from which the object information originates. This number is used to cross-reference object profiles 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:
The name of the Local ID field is configurable and may 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 may identify a group of objects. For example, if a family shares the same account or insurance policy, every family member has the same identification code for that account or policy.
|
 Copyright © 2011, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
