This section is to definitively list and define the terms used in an Omni-Gen™ conversation and to facilitate better product understanding. The dictionary of terms will be updated with future releases. Note that this is not a full dictionary of terms and is meant to be just a high-level familiarization document. A detailed understanding of these and other terms require proper training and review of the provided user documentation.
A product used by the Omni-Gen Server for cleansing, matching, and merging.
The individual items that make up a subject.
For example, the subject Person has the attributes of last name and first name.
Part of MDM subjects and their attributes that need to be verified for format, as well as accuracy.
A common example is the handling of zip code for zip+4 treatments.
Users of the Omni-Gen Model for purposes of remediation or post Master processing.
360 Viewer, Consumption Views, Health Views, WebFOCUS, and in the future publish-subscribe.
Set of views derived from the Omni-Gen Model. It is generally denormalized.
A tool to help consumers of the Omni-Gen Model understand what they have modeled.
A user who works with the 360 Viewer and processes remediation tickets.
An archive derived from the Project Bundle, which contains artifacts for Omni-Gen Server, Management Central Domain Service, Management Central Remediation Service, Cleansing, Matching, Merging, and other artifacts.
For more information, see Master Record.
Similar to consumption views in that they are derived from the Omni-Gen Model. However, it is now only available with Omni Patient.
An XML document that is used to define a Subject. It also serves the purpose of defining how Omni Instance Documents (OIDs) are produced for processing. It is also known as Inbound Document Specification.
A record from a participating source application for a subject. It can be generated at data load time or can be the result of a change in the source system.
An Eclipse-based tool to author the Omni-Gen model, as well as the cleansing, matching, and merging rules used by the Omni-Gen Server. It encourages team development and allows interaction with the Omni™ Designer Development Server to provide version control and release packaging.
Server component providing Project Bundle lifecycle management, treating Project Bundles as SVN artifacts.
The Omni-Gen peer to OPMC. Instead of being prepackaged for a particular directory, it relies entirely upon the model authored by Omni™ Designer.
iSM is the platform on which Omni-Gen Server runs.
Kibana is the Viewer in ELK. For more information, see ELK.
Log Stash is the log forwarding agent in ELK. For more in formation, see ELK.
A sub-component of the OGC that decouples the 360 Viewer from the data models that support it.
Provides remediation workflows and a supporting data model for the lifecycle of remediation tickets in the OGC.
The merged result of Instance Records that have been cleansed and matched.
As part of MDM, matching is the act of identifying a set of instance records as contributors to one or more master records.
The process of cleansing, matching, and merging data sourced by multiple systems for the lifecycle of that data.
Several transactional systems have different data for a worker. An MDM would produce a singular view of that worker.
Once instances have been identified as contributors to a master, the instance content for each is selectively brought into a master record. Note that not all instance attributes are required to be an attribute of the master record.
Represents an instance record for a subject and conforms to an IDS. For more information, see IDS.
A software platform for the process of Master Data Management that allows you to maintain your own set of subjects to master.
The collection of subjects, attributes, source codes, and references that are mastered and used by a user.
The Omni-Gen server is the document processing engine that consumes IDS-compliant XML documents for participation in the mastering process. It builds and interacts directly with the Omni-Gen Model.
An instance of Omni-Gen with a Patient data model pre-engineered for use.
An instance of Omni-Gen with a Health Insurance Payer data model pre-engineered for use.
Is a rapid deploy version of Omni Patient for the purpose of supporting the data mapping work done at the client site. It relies upon docker to execute.
The database conduit for IDS documents to be submitted for processing.
The collection of subsystems that provide a data steward to get a complete view of the Omni-Gen Model as well as the ability to remediate matching issues beyond the scope of the matching tool. OPMC comes packaged with metadata to support Patient or Payer data stewardship.
An upcoming feature allowing for the customization of processing in Omni-Gen.
Is an archived XMI file that represents a project authored in Omni™ Designer and housed in Omni™ Designer Server.
A feature that allows for a denormalized view of a subject in the Omni-Gen Model. Promoted data is presented as part of the root subject.
Binds subjects together in a parent-child relationship.
For example, the subject Facility has a Location.
The set of static data that is used as type identifiers and source codes.
A set of tables, similar to the Omni-Gen Model, that are used to load data from source systems.
Not to be confused with a software release from Information Builders, this is a release of a Project Bundle for use in Omni-Gen systems.
A specification for workflow processing expressed in XML. This is a component of Processing Rules.
For more information, see http://www.w3.org/TR/scxml/.
A web-based tool for working with Omni-Gen instances from development to production. It is the bridge between Omni™ Designer and the various subsystems.
A producer of instance records for one or more subjects.
An identifier that is unique to all other records produced for the subject by a source.
A person, place, or thing that is part of the Omni-Gen Model. A subject must be uniquely identifiable by its Source, Source Instance ID, and Subject Type. Additionally, the Subject must be a root object in an IDS document.
Used in some customer engagements to visualize results of Omni-Gen work.
A third-party tool for providing authentication and authorization behaviors in Omni-Gen. It may act as a proxy to clients LDAP/Active Directory or house the data in its own RDBMS.
A specification for expressing models, like Database models in XML. For more information, see Project Bundle.