Oracle® Healthcare Master Person Index Configuration Guide Release 4.0 E67164-01 |
|
|
PDF · Mobi · ePub |
This chapter introduces you to the Oracle Healthcare Master Person Index (OHMPI) configuration files, and informs you which XML files you can edit directly or with the OHMPI Configuration Editor. It also presents conceptual information for maintaining version control of the configuration files and provides rules you should follow when copying, cutting, and pasting files.
This chapter includes the following sections:
Oracle Healthcare Master Person Index provides a very flexible framework for creating a master person index application that is customized for your requirements. An Oracle Healthcare Master Person Index project includes several files in XML format that define the configuration of the runtime environment. You can configure a master person index application by modifying the XML files directly or by using the Configuration Editor. Make sure to verify the configuration of the application before deploying the project.
Note:
It is helpful to review the information provided in the Oracle Healthcare Master Person Index Configuration Reference to learn about the relationships between the files and what components and processes can be configured. Certain components can only be configured by modifying the XML files directlySeveral XML configuration files define primary characteristics of the master person index application, such as how data is processed, queried, and matched. These files configure runtime components of the master person index application.
In the wizard, you define the objects and fields contained in the object structure, along with properties for those fields. The information you specify is written to object.xml
in the master person index project. This file defines the objects stored in the master person index application and their relationships to one another. It also defines the fields contained in each object, as well as certain properties of each field, such as length, data type, whether it is required, whether it is a unique key, and so on. This file contains one parent object; all other objects must be child objects to that parent object. The object structure you define in object.xml
determines the structure of the database tables that store object data and the structure of the Java API.
In query.xml
, you configure the Query Builder component of the master person index application and define the available queries. In this file, you define the types of queries that can be performed from the Master Index Data Manager (MIDM) and the queries that are used during the match process. You can define both phonetic and alphanumeric searches for the MIDM. By default, these are called basic queries. You can also define blocking queries, which define blocks of criteria fields for the match process. The master person index application queries the database using the criteria defined in each block, one at a time. After completing a query on the criteria defined in one block, it performs another pass using the next block of defined criteria. Blocking queries can also be used in place of the basic phonetic query in the MIDM.
In mefa.xml
, you configure the Matching Service by specifying the fields to be standardized and the fields to be used for matching, as well as defining how the fields are standardized and matched. This file specifies the match and standardization engines to use and the query process for matching. Standardization includes defining fields to be reformatted (or parsed), normalized, or phonetically encoded. For matching, you must also define the data string to be passed to the match engine. The rules you define for standardization and matching are dependent on the standardization and match engine in use. Oracle Healthcare Master Person Index Match Engine Reference and Oracle Healthcare Master Index Standardization Engine Reference describe the rules for the OHMPI Match Engine and OHMPI Standardization Engine.
You can also configure portions of the match process in master.xml
, described below, which defines certain match parameters that control weight thresholds, how assumed matches are processed, how potential duplicates are processed, and the query to use for matching.
In master.xml
, you configure the Manager Service and define properties of the match process. You specify the match and duplicate thresholds in this file, and define certain system parameters, such as the update mode, how to process records above the match threshold, how to manage same system matches, and whether merged records can be updated. This file also specifies which of the queries defined in the Query Builder to use for matching queries.
This file also configures the EUIDs assigned by the master person index application. You can specify an EUID length, whether a checksum value is used for additional verification, and a chunk size. Specifying a chunk size allows the EUID generator to obtain a block of EUIDs from the sbyn_seq_table database table so it does not need to query the table each time it generates a new EUID.
In update.xml
, you define formulas that determine which data in an enterprise record should be considered the most reliable and how updates to the single best record (SBR) will be handled. The survivor calculator uses these formulas to decide what data from each system record to include in each object's SBR. The SBR is the portion of the enterprise record that represents the data that is considered to be the most accurate and current for an entity.
The SBR is defined by a mapping of fields from external system records. Since there might be many external systems, you can optionally specify a strategy to select the value for an SBR field from the list of external values. You can also specify any additional fields that might be required by the selection strategy to determine which external system contains the best data, such as the object's update date and time.
You can create Java classes that define special processing to perform against a record when the record is created, updated, merged, or unmerged. These classes must be created in the Source Packages folder of the EJB project and can be specified for each transaction type in update.xml
.
You can further configure the survivor calculator, blocking query, and match process by defining exclusion lists in filter.xm
l. Exclusion lists allow you to define values that should not be populated into the SBR, that should not be considered in the composite matching weight, and that should be ignored in the blocking query. Values you would want to filter out primarily include default values that are used when the actual value for a field is unknown. Default values can cause the blocking query to return records that are not a close match and can skew matching results.
By default, validation.xml
defines certain validations for the local identifiers assigned by each external system. You can create custom Java classes that define rules for validating field values before they are saved to the master person index database. You can then specify the Java classes in validation.xml
to make them part of the master person index application.
This file defines security roles and permissions for the client applications that access the master person index database.
For information on the midm-security.xml file, see the Oracle Healthcare Master Person Index Data Manager User's Guide.
In midm.xml
, you configure the appearance and processing properties of the Master Person Index Data Manager (MIDM). In this file, you define each object and field that appears on the MIDM, along with the properties of each field, such as the field type and length, field labels, format masks, and so on. You can also define the order in which objects and fields appear on the MIDM pages.
This file defines several additional properties of the MIDM, including the types of searches available, whether wildcard characters can be used, the criteria for the searches, and the results fields that appear. You can also specify whether an audit log is maintained of each instance data is accessed through the MIDM. For healthcare-based master person index applications this supports the privacy rules mandated by the HIPAA regulation for healthcare.
Finally, midm.xml
defines certain implementation information, such as the application server in use, debugging rules, and security activation.
The files that configure the components of the master person index application are created by the wizard and define characteristics of the application, such as how data is processed, queried, and matched, and how it appears on the MIDM. These files configure the runtime components of the master person index application.
The match-ext.xml
file provides the capability to create variations in sets of match fields and agreement/disagreement weights at runtime. Using frequency-based agreement weights adjustment, field value swapping, weight cap on a set of selected fields, and then based upon the type of data you provide, it enables the OHMPI Match Engine to compute more accurate matches when a specific behavior is desired.
This file extends the matching functionality you can perform on your OHMPI projects.
Note:
For information about the new matching enhancements in the OHMPI Match Engine, see the Oracle Healthcare Master Person Index Match Engine Reference.Make sure that when you modify the configuration files, you use the versioning controls in NetBeans to maintain version control. Even if you modify the files using the OHMPI Configuration Editor, check the files in and out before and after using the editor.
There are a few restraints on modifying these files. In addition to the general rules listed below, the match or standardization engine you choose might place other requirements on customizations. Be sure to review Oracle Healthcare Master Person Index Match Engine Reference and Oracle Healthcare Master Index Standardization Engine Reference before modifying mefa.xml
.
Keep the following guidelines in mind when modifying the XML files directly.
All fields specified in any of the configuration files must be included in object.xml
.
If you add fields to the object structure, make sure you add them to the survivor calculator in update.xml
.
If you define additional fields for normalization, parsing, or phonetic encoding, make sure to add the normalized, parsed, and phonetic fields to object.xml
and, optionally, the blocking query.
After modifying any of the configuration files, you must regenerate the master person index application and redeploy the project. You must also refresh any client projects that reference the master person index server project.
The Configuration Editor has built in validations to ensure that integrity is maintained between the configuration files. For example, it does not allow you to define a field for normalization if that field is not already defined in the object structure. While you can use the Configuration Editor to modify most of the configurable components, some components can only be modified using the XML editor. Following is a summary of which features can be configured using the Configuration Editor and which need to be modified using an XML editor.
You can modify most elements of object.xml
using the Configuration Editor. The following can only be modified using the XML editor:
Database type
Date format
Maximum field value
Minimum field value
It is not recommended you change the database type, but if you modify the database type or date format elements, you need to regenerate the application to create the updated database scripts. This does not recreate the Systems or Code Lists scripts; that needs to be done manually.
You can modify all elements in query.xml
using the Configuration Editor. If you create a query to use in the MIDM or to use for the matching query, you need to add the query to the appropriate file manually (master.xml
or midm.xml
).
Most elements in master.xml
cannot be modified using the Configuration Editor. You can only modify the duplicate and match thresholds from the Configuration Editor.
You can use the Configuration Editor to modify all commonly modified elements in mefa.xml
, including defining standardization structures, normalization structures, and phonetic encoding. If you create custom classes to implement a block picker, pass controller, match engine, or standardization engine, you need to specify the implementation classes in this file using the XML editor.
The Configuration Editor does not modify update.xml
. If you make any changes to the object structure (either through the Configuration Editor or XML editor) review this file to verify that all fields or objects are included in the survivor strategy and that the field and object names are correct.
The Configuration Editor does not modify validation.xml
. If you create a custom field validation class, you need to specify the implementation class in this file using the XML editor.
Most elements in midm.xml
are not modified using the Configuration Editor. You can add and delete fields that appear on the MIDM and modify the display name and the value and input masks. All other field properties can only be modified using the XML editor.
Field integrity is maintained when you delete a field using the Configuration Editor. The field is automatically deleted from the MIDM object structure and from any MIDM page definitions that include the field, such as a search page or report.
You can modify all components of the Match Configuration file using the Configuration Editor, including adding and removing comparators. The Configuration Editor does not validate the extra parameters that can be used for certain comparators, so you should verify your changes by reviewing the match configuration file manually.
Whether you modify the XML files directly or configure the master index application through the OHMPI Configuration Editor, be sure to maintain version control by checking files out before modifying them and checking them back in after you are finished. You can use any of the NetBeans supported platforms for version control. When working with the Configuration Editor, make sure to check out each file that will be modified, either directly or indirectly. For example, if you add a new field to the object structure, add the field to the match string, and add the field to a blocking query, the Configuration Editor updates object.xml
, query.xml
, and mefa.xml
.
You can use standard cut, copy, and paste commands to copy or move files between projects. OHMPI follows the standard NetBeans functionality, with the exception that you can only copy or move a component from one project into the same node of another project. For example, you can only paste a copied configuration file into the Configuration node of another project. In addition, you cannot cut components that are essential to a project, such as the configuration files, match and standardization files, and so on.