Glossary for virtual MDM

This glossary contains terms and definitions applicable to virtual MDM.

Active attribute
A status of “A” indicates that the attribute displayed is the most current, active value of the attribute. An attribute can have more than one active value depending upon settings in the database.
Aggregation
The process of amassing or gathering individual parts of information (data) from disparate systems to create one complete customer view.
Algorithm
A step-by-step procedure that compares and score member attribute similarities and differences. The algorithm has these steps: Standardize, Bucket, and Compare. The final step, Compare, is what yields the score. The algorithms are applied to data to create tasks and support search functionality, and are tailored to use attributes specific to your business.
Algorithms tab
A component of the InfoSphere® MDM Workbench Configuration Editor that allows for quick and easy configuration of algorithms.
Anonymous values
To accommodate the occurrence of fictitiously entered member data without adversely affecting a comparison score, a list of anonymous values are maintained in the MDM database. For example, if a record is being entered into a source system and the Social Security information is not available, users may enter a value of 000-00-0000 or 999-99-9999. In such a case, if these numbers are seen in the SSN field, they are not considered by the algorithm in the comparison. The algorithms are configured to not assign a score to attributes containing anonymous or missing values.
AutoLink MS
(Linkage type.) Indicates records that are compared from multiple sources that scored above the auto-link threshold. When this occurs, a common entity ID is assigned by the operational server.
AutoLink SS
(Linkage type.) Indicates records that are compared from the same source, which scored above the auto-link threshold, indicating that they are duplicates. A common entity ID is assigned by the operational server. Same source linking can be disabled.
Auto-link threshold
This threshold setting determines the score at which linkages are created. Records with comparison scores above this value are deemed to have a high likelihood of representing the same person, and are automatically linked and assigned a common entity ID. These records can be manually reviewed if your workflow process deems it necessary. The auto-link threshold can be customized to meet the needs of your organization.
Auto-timeout
To assist in data security, many applications have been designed with an automatic timeout feature. If a user is logged in to an application and does not interact with the application (for example, performing a search or editing an attribute) for a pre-defined time, the application automatically logs the user out of the system.
Auto-unlink
The definition differs slightly depending on whether you have transitive or non-transitive linking configured.
Bootweights
Pre-determined, hardcoded weights that are used to start the weight generation process.
Bridge member
In the context of group entities, a member that is associated with more than one bucket.
Broker
Refer to related topics.
Bucket and bucketing
Part of the derivation process in which the operational server groups specify attributes for use by the candidate selection process. Examples of possible buckets are: Last Name + Phone, or Last Name + Email Address, or Last Name + First Name. Buckets are defined during your initial configuration of your MDM implementation by the project team and can have one or more attributes per bucket.
Bucket data
The output of the derivation attributes configured to participate in the candidate selection. For example if you have a bucket configured for Address, the bucket data for an address might be 1043_W_EASY_ST_85545. The standardized string is converted to a format that makes for quick access during candidate selection. Bucket data is created during the derivation process after standardization.
Bulk cross match (BXM)
A process that allows you to compare and link thousands of records per second. The BXM is most commonly performed in the initial stage of the implementation and again just before the system goes live. The BXM process is made up of two primary utilities: MPXCOMP (Compare Members in Bulk) and MPXLINK (Link Entities).
Callback handler
Custom code that defines the callout logic. Used by the operational server to call out to third-party systems or to implement conditional security, event notification, or more processing steps.
Candidate
When a search request is sent to the operational server, the operational server returns a list of individuals that meet the search parameters. These individuals are referred to as candidates.
Candidate selection
The behind-the-scenes process whereby records stored within the MDM database are selected, based on common buckets, for comparison against another member record to determine a potential match. The selection process uses the values of an incoming record to compare against existing member records with similar buckets and the returned result is a list of candidates who share at least one bucket in common. This list of candidates then proceeds to the comparison stage.
CDI (Customer data integration)
The sum of procedures, automation, and skills that are required to standardize and integrate customer data that originates from different sources. CDI attempts to address the situation when two or more sources that contain records referring to an overlapping set of real-world customers lack unique identifiers that show the correspondences between the records in the multiple sources. Furthermore, the records representing the same entity might have differing information. For example, one record might have the address that misspelled, another record might be missing some fields, and so on.
Clerical review threshold
Scoring levels that determine how records are managed in the operational server. This threshold setting is compared to the linkage score generated by the comparison routines and algorithms. Records with comparison scores above this value – but below the auto-link threshold – are added into a review queue for manual determination of the linkage or potential data issue. Records that compare below this threshold have such a small likelihood of being the same customer that task creation has little value and therefore, a task is not generated. Clerical review threshold might be customized for your organization.
Cloud
(InfoSphere MDM Inspector functionality) When the number of relationships of a specific type exceeds the threshold that is set during configuration, a cloud displays in the Relationship View.
cltdicd
A file containing database metadata that is defined for a software configuration at the time of system configuration.
Comparison
The application of one or more algorithms to determine similarities and differences between two or more records. This process compares the individual attributes—attribute by attribute—of each record that is selected during the candidate selection process.
Comparison data
Each algorithm that is implemented is configured to compare certain attributes. Such identified attributes are extracted from the core data, standardized, and stored as comparison data in the derived data layer of the MDM database. Comparison data is formatted and stored in a manner that allows for fast access and comparison. Comparison data is stored in the MDM database.
Comparison score
The score that is returned for records after the comparison process. Comparison scores might result in task or linkage creation that is based on the thresholds that are set for your organization. The higher the score, the more likely that the records represent the same person.
Composite view
A composite view is a defined way of displaying attribute information that represents a complete "picture" of a member. For example, a composite view can be either EMCA - Entity Most Current Attribute or MMCA - Member Most Current Attribute.
Consuming system
These systems (for example, a radiology system) consume, rely upon, or use identity information such as a medical record number, frequent customer number, or other identifiers assigned by a source system to identify a given object or member. Consuming systems are often referred to as transactional systems. It is possible for a system to be both a source and a consuming system, such as registration or reservation systems.
Context pool size (ContextPoolSize)
The number of operational server threads that are started concurrently. Each context pool has its own connection to the database and can operate independently of the others. If you have your context pool set at 5, for example, you can send in five searches or gets or puts at the exact same millisecond, and they are all processed concurrently. If six are sent, then the first five process while the sixth waits for the next free context.
Controlled view
This type of composite view displays a selection of various attributes from multiple specified sources. For example, you can specify to display name and address from Source A, phone and birth date from Source B, and Social Security number and address from Source C.
Core member data
The complete set of data (all attributes) about a member that is stored in the MDM database. This set might include historical data for a member as well as the most up-to-date version.
Cross bucketing
In group entity functionality, cross bucketing occurs when a member acts as a bridge between two or more non-related member sets.
Customer profiling
The practice of mining data to gain a complete picture of each customer that is known in a data source. Successful customer profiling enables businesses to identify information such as customer purchase habits, special requests, brand loyalties, and transaction history.
Data extract file
A file that is generated from a source system or database for inclusion in the operational server. The MDM Workbench Derive Data and Create UNLs (mpxdata) job or the MDM mpxdata stage (used in IBM® InfoSphere DataStage® and QualityStage® Designer client) can be used to process the file.
Data files
Files that are written by message broker interfaces containing messages relevant to the processing of HL7 or XML messages. Examples include: input.dat, success.dat, and reject.dat.
Data manager
The data management role that is responsible for the project management aspects of a CDI (Customer Data Integration) or MDM implementation at an enterprise. This role manages stakeholder expectations, the team of data stewards and the successes of the project from a cost and time perspective.
Data profiling
Data profiling enables users to view various aspects about the data (attributes) stored in their sources systems to better understand and improve the quality of the data. Specifically, you can determine what sources have or are creating bad or incomplete data, which ultimately affects your overall business operational and financial success.
Data steward
The data management role that is tasked with maintaining and implementing the data governance policies agreed upon by the company. Data stewards are often the individuals using the InfoSphere MDM Inspector application to resolve data issues.
Definitional source
A definitional source is one in which members (records) are created and usually updated.
Delete
(Linkage type). Indicates that an InfoSphere MDM Inspector user logically deleted the record—the record is no longer used in algorithmic comparisons.
Deleted attribute
An attribute status of “D” indicates that the attribute has been logically deleted.
Demographic data
Information describing a person or object (for example, name, address, part number, organization).
Derivation process
The process that includes these steps: 1) standardization of the data, 2) creation of bucket data, 3) creation of comparison data, and 4) creating binary files that are used for the bulk cross match and weight generation processes. Not all core member data goes through the derivation process; only attributes used in bucketing and comparison participate in this process.
Derived data
Data resulting from the derivation process; this attribute data is configured to participate in comparison and scoring. Derived data is stored in the MDM database.
Deterministic matching
A rules-based process to determine a match between two records. The process works best for simple, easily defined matches that is used for matching of relationships and hierarchies.
Duplicate record
Two or more records representing the same person or object that are stored in the same original source system.
Dynamic task creation
Tasks that are not saved as sets in the MDM database. Rather tasks are generated each time that the operational server runs a comparison (for example, during task searches, data loads, and data updates). The exception to this dynamic task model occurs when records in a task have their workflow status set to “deferred.” This setting then saves the records as a task set until the task is resolved.
EID
Entity ID. Refer to related topics.
EID synchronization
Also called entity ID update. This process, which is configured in the Outbound Broker configuration files, can be used to propagate entity ID changes made in the operational server to source systems.
EMCA
Entity Most Current Attribute. An EMCA composite view displays the most current attributes for any member within a defined linkage (members that share a common entity ID). The attributes are combined so that the view of the entity (for example, person) is a conglomeration of attributes from your various source systems.
EMPI
Enterprise Master Patient Index. Used in the healthcare industry, an EMPI contains unique identifiers for each person or patient.
Encounter data
Dates and information regarding a member''s visit to a facility within your organization.
Enterprise customer identity management
The process of identifying all of the information for a customer (member data) throughout the enterprise, linking it together for a 360-degree view of a member and maintaining that view going forward.
Entity ID
The identifier number that is used to represent an entity (which is the same person or object across multiple sources or within the same source). This identifier is assigned by the operational server and can be shared by more than one member record.
Enterprise Service Oriented Architecture (ESOA) Toolkit
The Enterprise Service Oriented Architecture (ESOA) Toolkit is a Java™ application programming interface (API) and SOAP web service generator that generates an API in both Java and web service forms. SOA stands for services-oriented architecture.
Entity manager
A process within the operational server that facilitates comparison and entity definition. As new members or updates reach the MDM operational server, the associated MemRecnos are added to a work queue. The entity manager scans the queue and when it finds an updated member, a cross-match is triggered. Depending on the configuration of the system, the results of this cross-match might be used to link new entities, change existing linkages, or create tasks to allow for further review. The entity manager operates in synchronous or asynchronous mode. If the entity manager is running in synchronous mode, comparison is done between derived data creation and storage in the database. If set to asynchronous, the data is stored in the database before comparison is performed. The entity manager can also be set to on or off, with the default being on.
EntRecno
The internal database reference to the entity ID assigned to a record.
Environment
Environment refers to the type of data—Test or Production—and specific system (server) to which a user has access.
ER
Entity resolution.
Error types
False negative and false positive. Algorithms improve the accuracy of linkages. First, they reduce the overall number of inaccurate linkages by simultaneously reducing the occurrence of false negatives. Second, the algorithms reduce false positive results when matching records.
ETL
Extract, transform, load. A process of extracting data from a source database, transforming, and formatting it to meet to the needs of the system that consumes it, and loading it into a destination database.
Event
A transaction that triggers a change to a member in the MDM database.
Event date
The date that is associated with incoming transaction messages to the MDM database. Data in these messages are added or updated to appropriate member records.
Event initiator
The person (user) or process that creates an event. For example, the term “Registrar” might display on the Event Summary report, which indicates that the registration process created the associated event.
False negative
Two members not linked that are the same person.
False positive
Two linked members that are not the same person.
False positive filter
Functionality within the operational server that assists in correctly determining whether linked records are the same person. This functionality is helpful when working with family records, especially twins or Senior and Junior names.
Fixed segments
The set of standard, packaged segments that are shipped with the product.
Get
A process that is used in the retrieve functionality of InfoSphere MDM Inspector and Enterprise Viewer, or by applications developed using the SDK. Associated with the MEMGET interaction, this functionality retrieves a specific record via entity ID or source ID. This function is not a search, and therefore a comparison score is not returned.
Glue member
The record in a linkage set to which all other records in the set are linked. In other words, the record bringing the linkage set together.
Group entities
In normal processing, a record can belong only to a single entity within an entity type. Group entity functionality enables records to have multiple entity record numbers (entRecno) within a single entity type. A member of a group entity must match all members of that entity set above the auto-link threshold.
Groups
Groups (user groups) and their associated system privileges are established within InfoSphere MDM Workbench to assist in controlling system security. As users are added, their access to sources and their ability to view or update attributes can be controlled by assignment to an appropriate group.
Hardlink
When working with organizational hierarchies, a hardlink occurs when members compare above the auto-link threshold.
HasShadow
System-trigger task type. When tasks are created, users have the ability to modify data via InfoSphere MDM Inspector to resolve the issue. If resolution required that the member attribute data be modified, that attribute is assigned a status of S for “shadow” and a HasShadow trigger is sent to the outbound broker. The outbound broker then creates a message reflecting the attribute change and sends it to the appropriate source system. When the client system is updated with the change, a confirmation message is returned to the operational server via the inbound broker. When the confirmation is received, the attribute status changes from Shadow to Active.
Hierarchy
The relationship between two or more entities by virtue of a parent-child identifier on one or both of the records. A member record might have one and only one parent for a given hierarchy type and that parent must be in the same source as the child.
Hierarchy tree
A visual image of a hierarchy. A tree can be one or multiple levels deep.
Hints
Refer to related topics.
Historical attributes
Attribute values that are no longer active (or valid) for historical reference. These attributes might be used in comparison or matching depending on your configuration. The number of values you store is controlled via the nsExists field in the mpi_segattr table.
HL7 Query Adapter (Query Broker)
Functionality that enables message-based requests from customer applications to be sent to the operational server for the retrieval of information about a member (or member's entity). The information is returned to the requesting client via a message-based response.
Hook point
The location that callback invocation occurs during operational server processing.
Household and household entity
An entity type; multiple individuals who are associated with the same physical location, and share common attributes of home address and phone number (for example, family members and non-family members sharing a household). Members of a household entity share a common entity ID.
Identification task
Unit of work, created by the operational server, which facilitates user review, and possibly resolution. Also, sometimes called identity task.
Identifier
A number or code referring to a specific individual.
Identity domain
A set of systems that includes a source system and a collection of consuming systems. Each system in a given identity domain uses the same unique identifier. The operational server enables the integration of information across multiple identity domains.
Identity entity
An entity type; a single individual whose records are grouped by demographic attributes.
Identity rule
An identity rule is applied when two members have been given the same entity ID.
IMM
IBM Member Model. IMM refers specifically to the .imm file within an InfoSphere MDM Workbench configuration that contains the dictionary settings (for example, settings for members, attributes, segments, and so on). The .imm file is an XML file that is stored on your local system. After the configuration is deployed to the server, these settings reside in the database. The .imm file does not store the algorithm.
Implementation-defined segments
Custom member-attribute segments are tables in the database for storing member data, and implementation-defined segments are those that are not part of the fixed segments that are shipped with the product.
Inactive attribute
An attribute status of inactive (“I”) indicates that an update has been made to the specific attribute and the “inactive” value represents old information. These attributes are used in record comparison.
Inbound broker
The inbound broker, part of the message brokers, is a generic interface that is designed to manage client-specific extensible markup language (XML) or health level 7 (HL7) messages. To process messages successfully, two services are installed: a message reader and a message processor.
Informational source
Informational sources typically provide “valid” values that can be used as attribute values. For example, an informational source might provide valid credit card numbers or frequent flyer numbers. Member records are not created in informational sources.
Interaction
A request from a client application, such as InfoSphere MDM Inspector, to the operational server and the result of that request from the server back to the client. When creating users and groups in the InfoSphere MDM Workbench, you can specify interaction permissions, which means that you are specifying the actual functions a user can perform.
Invalid reference
(Relationship Task type) A type of task in which an entity (according to its data and creation rules) wants to have a relationship with another entity, but the target entity does not exist within the operational server.
Linkage
Two or more records that are associated by a common entity ID.
Linkage modification date
The date a linkage was modified—any change made to a member or record in a linkage set (for example, entity ID change or status update)—in the MDM database.
Linkage set
A grouping of two or more records that have a high likelihood of representing the same person. An unlimited number of records can be included in a linkage set, which may contain records from a single source or multiple sources.
Linkage status
The label that is assigned to a linkage set that tracks user review. The status types can be customized, but usually include ‘Examined OK’ (linkage has been reviewed and confirmed) and ‘Examined Error’ (linkage has been reviewed and an error in the linkage is confirmed).
Linkage type
Label that is assigned to a linkage set associated when an entity ID assignment is made by InfoSphere MDM or by a user. Examples of linkage types include AutoLink-SS and ManuLink-MS.
Log files
Files that are written by the message interfaces containing information relevant to the operation of the specific process. Examples include: mpinet.mlg, msgread.mlg and msgproc.mlg files.
Logical deletion
Reference to a record that remains in the database, but is not included in comparisons or retrieved in searches.
Madlogs
Log files that are created by the operational server processes. Includes both log files and data files.
ManuLink-MS
(Linkage type.) Indicates an InfoSphere MDM Inspector user manually linked records from multiple sources.
ManuLink-SS
(Linkage type.) Indicates an InfoSphere MDM Inspector user manually linked records from the same source.
Many-to-many relationships
General term to describe grouped entities.
Mapping message manager (message broker)
The mapping message manager (also called mapping broker) provides a way to query the operational server by reading messages from an input queue, requesting data from the MDM database, and then writing to a message queue. A mapping message broker instance is used for two basic purposes: retrieving information and searching for information.
Match
A selection of records that match some of the attributes of a specific record. When the match interaction is performed, the operational server retrieves the record for the source ID and source system specified and then compares all the attributes of that member to similar attributes of other member records. The match interaction operates in the same manner as the entity manager—using the thresholds—and only returning those members that are above the CR threshold, or that take part in a review identifier task.
Matched pairs
Two members that are identified as the same person by the operational server.
MCA
Most Current Attribute. The most current attribute value.
Member get interaction
MemGet. This interaction is used to retrieve a specific member by using a member key value such as an entity ID or a source ID and source code. MemGet is used by the retrieve function in an application such as InfoSphere MDM Inspector.
Member logical model
A read-only view of the members, attributes, and segments that are defined for an implementation. When defining external attributes and enhanced composite views, member logical models are imported in the InfoSphere MDM Workbench tool.
Member match interaction
MemMatch. This interaction performs a cross-match of a single member specified in the input, against the other members that are stored in the MDM database.
Member put interaction
MemPut. The MemPut interaction “puts” member data in the MDM database. The interaction has several options that control exactly how the data is stored. When you update a member's attributes, whether through an application like InfoSphere MDM Inspector or updates from a source system, the MemPut interaction is used.
Member search interaction
MemSearch. Uses selected criteria, such as name, date of birth, address, and gender, to search and return a list of records matching the criteria. The interaction creates a “virtual” member that is based on the attribute criteria that are submitted and compares those attributes with other records in the database. MemSearch is used by Search functionality in applications.
Member status
The current status of a member; status can be Active, Overlay, Merged, Deleted, or Fictitious. A Merged member becomes obsolete. The Deleted status indicates the member has been logically deleted.
Member type
A member type defines the kind of member data that is stored and managed in InfoSphere MDM. Member type definition enables products for use in multiple business environments.
MemRecno
Each record that is stored in the MDM database is assigned a unique member record number. This number serves as the surrogate primary key for a member.
Message broker
Refer to related topics.
Message processor
A stand-alone process (or service) that processes HL7 or XML messages from an input queue. The messages are sent via a TCP/IP connection to the operational server. The operational server attempts to process the message and sends a notification of success or failure to the message processor. Finally, the message processor writes the message to a success queue (for example, success-yyyymmdd-tttt.dat) if the message was processed successfully, or to a reject queue (for example, reject-yyyymmdd-tttt.dat) if the message was not processed successfully.
Message reader
A standalone process (or service) that receives HL7 or XML messages through a TCP/IP connection. The process reads messages from the socket and writes them to a queue so the message processor can consume them.
Missing relationship
(Relationship Task type) A type of task in which an entity is supposed to have a relationship, according to the relationship type constraints, but does not. For example, a patient might be required to have at least one provider. If there is a patient, which does not have a provider, a task would be created.
MPI
Master person index. The MPI is a system that provides a complete picture of data for a person that is gathered from other source systems.
MPINET
A process that runs on the operational server. Client applications, as well as the inbound and outbound brokers communicate with MPINET requesting the operational server to perform various interactions.
mpxdata configuration file
The Derive Data and Create UNLs (mpxdata) job uses the mpxdata configuration file as a map for reading the customer's data extract file and as a legend for converting the data to the operational-server database table layout. The configuration file tells mpxdata where each field is in the extract and how to migrate it into the proper data format.
Multiplicity relationship
(Relationship Task type) A type of task in which an entity has too many of a particular kind of relationship, for example, a patient with more than one provider, or an organization with more than one owning organization.
NoChange
(Linkage type.) An InfoSphere MDM Inspector user updates the workflow status, but does not make a change to the entity ID.
Non-event
An action that is not defined as an event type in the event table. The terms None or Non-Event are often seen on event summary reports.
Non-identity rules
Rules that indicate that the specified records are not the same person. A non-identity rule is created when two records have been reviewed and a user has manually determined that they are not the same person. This determination prevents those records from being placed together in a task later.
Non-obvious relationships
In group entities, a relationship that exists between members that have a common bridge member.
Non-simple EID
An entity ID shared by more than one record (records that have been linked).
Non-transitive entity
Records in a non-transitive or strong entity, must match above the auto-link threshold with all records in the entity set. Members of a non-transitive or strong entity can belong to only one entity type set at a time (one entity ID).
Operational server callout
The functionality that enables the operational server to increase its reach via callback handlers. Callouts extend the capabilities of virtual MDM by interrupting the normal process (whether beforehand or afterward) of querying a web service, validating data values, and implementing logical statements around interactions in order to make automated decisions regarding how best to handle the data.
Organization
One of the defined entity types. Organization is used in the business or corporate environment to accommodate the management of organization data.
Outbound broker
A mechanism that reduces manual effort by automatically updating source systems with data changes and identifier updates that are made in the operational server. If a legacy system does not allow updates directly from the MDM operational server, an outbound screen scrape option is available to process updates.
Overlay
An overlay occurs when one member's information overrides the information of another, different, member record.
Owner
The operational server assigns owners to tasks based on modifications to task data. Owners include authorized users of the software and applications. Typically, “System” is the default owner until a user begins to work and modify a task.
Path to root
When viewing a hierarchy tree, this tree starts from a selected member, and moves up to the top level, or rooted member.
Person
One of the defined member types. In the user documentation, the term “person” may be used as an interchangeable term for person, patient, provider, or customer.
PIM
Product Information Management. The process of managing information about a collection of products with one centralizing system, including all data that is required to market and sell the products through multiple distribution channels.
Pivot record
The entity or record that the search was initiated with.
Potential linkage
(Identification Task type.) Records exist in different source systems that have a high likelihood of being the same person.
Potential overlay
(Identification Task type.) Two or more persons share the same source ID and their respective data has been commingled.
Premerge
(Linkage type.) After an InfoSphere MDM Inspector user has resolved a record as a duplicate and set the surviving source ID, the operational server sets the linkage type to premerge. The outbound broker generates a message to the source system reflecting the ID change. When the source returns a merge confirmation message to the MDM operational server, this linkage type is then set to “merge.”
Probabilistic algorithms
The comparison methodology that identifies multiple records that represent the same person. Probabilistic algorithms calculate scores that are based upon weights that are associated with values for specific attributes. This methodology is used across all searchable attributes making the approach much more accurate in identifying the most likely match of attributes.
Probabilistic matching
The process of using statistical analysis to determine the overall likelihood that two records match. Probabilistic matching is the preferred method for matching large data sets or when many attributes are involved in the matching process.
Proband
A record to which another record is being compared (the “trigger” member). In the Compare display, you may see a message such as “comparing proband 5 with candidate 3.” The numbers in the message represent the member ID number.
Promotion
Promotion occurs when a record, which was previously assigned to a task by the operational server, is updated or changed and that action “triggers” a new data issue or resolves the current issue. When this occurs, the software might automatically promote the record to a different task type. If the action resolves the data issue, the record no longer displays in task search results.
Provider
One of the defined member types. Provider member types are typically implemented in healthcare provider or payer environments to accommodate management of network provider data such as medical centers, doctors, and laboratories.
Real time
Data updates or changes that are stored and become effective as you make them.
Relationship creation
(Relationship Task type) A type of task in which an entity has a relationship that the operational server has detected should not be there (according to the creation rules). This occurs in a situation where a user has marked a relationship as “unmodifiable”.
Relationship creation rule
These are associated with a relationship type. A relationship creation rule indicates exactly how a particular relationship should be derived between entities.
Relationship task
A recorded event within the operational server that indicates that the operational server has detected a possible data quality issue with regard to one or more relationships.
Relationship type
The types of relationships between entities and members. For example, “boss,” “patient” or “customer.” Relationships are viewed in InfoSphere MDM Inspector and types are defined in InfoSphere MDM Workbench.
Re-parenting
When working with hierarchies, re-parenting occurs when an entity is dragged from its current parent and dropped on a new parent, resulting in a new parent-child relationship.
Review identifier
(Identification Task type.) Multiple persons incorrectly sharing unique identifying information, such as Social Security number.
ROC curve
A Receiver Operating Characteristic (ROC) curve is a plot of true positive rate against false positive rate for different threshold values. The Threshold Calculator generates one or more ROC curves to help administrators determine optimal clerical review thresholds and auto-link thresholds.
Routing message manager (routing broker)
The routing message manager (also called routing broker) enables messages to be routed from a single queue into multiple queues that are based on the information in the message. Routing message broker differentiates message types such as adds, changes, merges, and so on. For inbound traffic, the routing broker determines the message type and sends the message to the appropriate inbound queue. The message can then be processed in a specified manner. For outbound, the messages are routed to an outbound queue that sends the message to a specific destination.
Score or scoring
A number assigned by the operational server indicating the probability that the various records in a linkage set represent the same person. Specifically, the score is an aggregate of the individual comparisons for each attribute. Typically, the higher the score, the greater the likelihood that the records represent the same person.
Search
A search uses specific criteria, which are based on your attribute configuration, to locate a record or task in the MDM database.
Segment
Segments coincide with the MDM database data schema to define operational-server behavior and member information. Each segment coincides with a database table. A set of fixed or primitive segments are provided. For example MemName, MemAddr, MemIdent are all fixed segments.
Service model
The customer-defined data model that is used for identity services. Also referred to as a user-defined logical model.
Shadow attribute
When an attribute is updated for a member in the MDM database, the attribute is assigned a status of “S.” Shadow indicates that attribute values in the MDM database and the source system are out of sync. When this occurs, the outbound broker generates a message to the source system reflecting the attribute change. Once the operational server receives confirmation that the updated attribute value has been changed in the source system (via an inbound message), the status changes to “A.” Shadow attributes are used in comparisons.
Simple EID
An entity ID that is associated with only one member record. If a record has the same EntRecno (enterprise ID) and MemRecno stored in the MDM database, this might indicate that there is only one record in the entity and is thus called a "simple EID." If the EntRecno is not the same as the MemRecno, this indicates that the record has been or is part of a multi-member linkage.
Singleton
A single member with an entity ID that is not shared with other member records; one member record in the entity.
Softlink
When working with organizational hierarchies, a softlink occurs when members compare above the clerical review threshold and below the auto-link threshold.
Source
A separate system/database with which the operational server interacts and receives member information and updates.
Source ID (SrcRecno)
The number that identifies the source to the operational server. This identification is used by the operational server for synchronization and enhances record updates. The source ID is assigned to the source system from where the record originated.
Source ID status
Reflects the state of the source ID resolution; set by the system.
Source system
The system (application) from which a specific record in the MDM database originated. For example, a registration system or an accounting system.
SrcRecno
See source ID.
Standardized data
Part of the derivation process, standardization is the process by which similar data received in various formats is transformed to a common format that enhances the comparison process. For example, street names commonly contain directions, like North or West. The standardization routines formats these values to “N” or “W” in order to speed up the comparison process. The standardized data does not overwrite the core member data in the database; therefore, when you view a record it shows the original format (for example, North rather than “N”).
Surviving entity ID
When it is determined that two or more records from multiple sources are the same person, you may elect to assign one entity ID to all of the records. The entity ID that you ultimately assign to the records becomes the surviving entity ID.
Surviving source ID
When it is determined that two or more records, within a source, are the same person, you might choose to assign one source ID to all of the records. The source ID that you ultimately choose to assign to these records is the surviving ID.
Tag
A method for creating rules that direct the operational server in categorizing tasks. As issues are identified by the operational server, it considers the defined tags and automatically groups those tasks. Once tags have been defined, you can use the bulk assignment capability to search for tasks with a specific tag and then assign those tasks to a user or group. For example, you may decide that all tasks associated with a given source should be assigned to a Group A, while all potential overlay tasks be assigned to Group B and further, all potential overlay tasks within a score range be assigned to User1. Any tag with at least one rule is required to have an entity type association.
Task
Unit of work, created by the operational server, which facilitates user review and resolution. The types of tasks address identity data issues, custom tasks, and relationship tasks.
Task creation date
The recorded date a task was created by the operational server.
Task get interaction
TskGet. A cross-match using a member or entity task record as input to the cross match. A task get returns all members in the same entity as the input member, as well as any members that match above the clerical review threshold. Typically, this interaction is performed after you have done a task search and selected a specific member record to review. A related interaction, TskGet2, populates the new MEMRECNOs array in all task types.
Task hints
When you configure custom tasks, you can define hints that direct the InfoSphere MDM Inspector application to highlight certain fields in the task resolution screen to help InfoSphere MDM Inspector users find and resolve data issues that involve custom tasks. Hints, like the description field, are part of the data that is associated with a member at the time the custom task information is "put". Task information can be put into the MDM database by using the IxnTskPut2 interaction or the TSKPUT MDM stage.
Task life cycle
The process or cycle in which a task proceeds from point of creation to resolution.
Task model
The task model defines how tasks are defined and managed. The operational server uses a dynamic task model, which creates tasks each time a comparison is performed.
Task modification date
The recorded date of any changes to a task, including update information for a record or a change to workflow status.
Task put interaction
TskPut. This interaction enables modification of task level details for a member. TskPut is the mechanism that is used to create manual linkages or to dissolve linkages. For example, when you work a task in InfoSphere MDM Inspector and save the task changes, the TskPut interaction is performed. A related interaction, TskPut2, allows the use of the MEMRECNOs array to specify members that are associated to an individual task.
Task resolution
The act (end-user review and action) or process (such as automatic link) of correcting data to remove a task from the task queue.
Task search interaction
TskSearch. The task search interaction takes search criteria input (for example, task type, task owner, or task status) and returns a list of members with task issues.
Task set
Two or more records that are explicitly identified as being in a task. Task sets are stored in the MPI_Memxtsk (member tasks; typically review identifier and potential overlay) and MPI_Entxtsk (entity tasks; typically suspected duplicate) tables.
Task types
Tasks are generated by the operational server and are categorized as one of the following types: potential linkage, potential overlay, suspected duplicate, or review identifier.
Templates
Base system settings for specific member types or products such as IBM InfoSphere Master Data Management Patient Hub and IBM InfoSphere Master Data Management Provider Hub. After a base template is installed, project implementers can customize the settings for an organization.
Threshold
Scoring levels that are set for an organization to determine how records are managed. Records scoring below a certain threshold might be designated as having such a small likelihood of matching that no action is required. Records scoring between the lowest threshold level and highest threshold level might generate a task and require review or action. Records scoring above the highest threshold level might be designated as having a high likelihood of matching and are automatically linked.
Transitive entity
Transitive entities operate on the “glue member” concept in that a record only needs to match one other record in the entity set. This match can be achieved by comparing above the auto-link threshold or by manual linking. In transitive entities, a member can belong to only one entity at a time and thus have only one entity ID assignment.
Trigger member or trigger record
When a task search is requested, the results are generated in real time (at the moment the search is initiated). The record, or criteria, that the operational server uses to compare against other records (candidates) is called the trigger member or trigger record (the record triggering the comparison). When a task search returns results, the trigger member typically displays with a higher score than the other records. The score is higher based on the trigger record being compared against itself during the comparison process. The other records that are returned are issued comparison scores that are based upon their comparison against the trigger record. A record is also considered to be the trigger member if an update to that member causes a cross-match, which results in task creation.
Trusted source view
A trusted source composite view displays the attributes from one specified source. Typically this is a source that you know to have the most accurate information.
Undelete
(Linkage type.) Indicates an InfoSphere MDM Inspector user activated the record after it had been deleted.
Virtual attributes
Attributes that are not stored in the MDM database, but are used in derived data form. Defining virtual attributes is done through the mpi_segattr table, while defining a virtual source is done through mpi_srchead.
Virtual member
When a member search is performed, the operational server uses the criteria that are specified on the search screen to create a “virtual member.” Other records with similar attributes are then compared against this virtual member to determine the likelihood that they represent the same member.
Virtual source
If a source is defined as “virtual,” member attributes from the source are not written to the MDM database, but do participate in derived data.
Web services
Web services enable interaction between the operational server and web-based clients. Web services use the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL) standards enabling developers to program in multiple environments such as: Java, Perl, Visual Studio .NET, or any other language, which supports these standards.
Weight
In the operational server, a weight is a measure of the evidence that a comparison result provides for a match or non-match. Simply, a positive number indicates the result is evidence for a match while a negative number indicates the result is evidence for a non-match.
Weight generation
A process within the operational server that enables the generation and assignment of weight values to attributes. Weight assignments enable determination of a match or non-match between members. The weight generation process is run from InfoSphere MDM Workbench.
Workflow status
Indicates where a task stands in the resolution process (for example, an “unexamined” status indicates the task has not been reviewed, while a “deferred” status indicates that the task has been reviewed but not yet resolved) or, for resolved tasks, indicates the resolution (for example, same person, not the same person). Workflow statuses can be customized for each client.

Last updated: 22 March 2021