| Oracle® Healthcare Master Person Index Release 1.1 |
|
|
This chapter provides information and a procedure for creating an Oracle Healthcare Master Person Index application. It also provides information about master person index wizard field properties and name restrictions, and custom plug-ins, including how to implement custom plug-ins, and generate a master person index.
This chapter includes the following sections:
"Understanding Master Index Wizard Name Restrictions and Field Properties"
"Learning About Custom Plug-Ins for Master Person Index Custom Components"
The wizard provides a simple method for you to create the object definition and the runtime configuration files for your master person index application. This section provides instructions for creating a new project and using the wizard to create the configuration files for the master person index application. To create the initial master person index framework, follow these steps.
If you plan to use a language other than United States English you need to set your computer to the desired language and country, for example Spanish in Mexico.
Note:
If using an operating system other than Windows, see your computer system's manual.Click Start, select Control Panel, and then double-click Regional and Language Options.
The Regional and Language Options window appears.
With the Regional Options tab selected, under Standards and formats, choose Spanish (Mexico) from the drop-down list.
Under Location, choose Mexico from the drop-down list.
Click Apply and then OK.
When your computer system is set to Spanish and you create an OHMPI project, a copy of midm_person_spanish.xml will be created in the project_dir/src/Configuration folder.
Note:
This file (
midm_person_spanish.xml) is based upon the Person template and is translated into Spanish. For projects created with the Person template, you can replace the midm.xml with this file.When you create a new Oracle Healthcare Master Person Index project in NetBeans, the wizard for creating a master person index application automatically appears.
On the NetBeans toolbar, click New Project.
The New Project wizard appears.
Under Categories, select MDM.
Under Projects, select Master Person Index Application and then click Next.
The Project Name page appears.
Enter the project name and the path where you want to store the project files in the upper portion of the window.
Enter the application server and Java version you are using in the lower portion of the window.
To make the Master Person Index project a main project, select Set as Main Project.
Click Next.
Continue to "Step 2: Name the Master Person Index Application".
Before you can configure the new master person index application, you must give the master person index application a unique name. It is a good practice to give each master person index application a unique name you create because certain components within the application server are based on the application name. Dependent components include the data source for the JDBC connection and the outbound Topic (if one is used).
In the Application field of the Name Application window, enter a name for the new master person index application, and then click Next.
Note:
Give the application the same name you will give to the parent object when you define the object structure.The Define Source Systems window appears.
Continue to "Step 3: Define Source Systems".
After you specify a name for the new master person index application, you need to specify the processing codes for the source systems that will be integrated into the master person index system.
Complete "Step 2: Name the Master Person Index Application".
In the Name field of the Define Source Systems window, enter the processing code of one of the source systems that will share data in the master person index system, and then click Add.
You can enter any of the following characters:
! _ ~ ( ) { } + \Q # $ % & : ; - /
a-z
A-Z
0-9
þ ÿ Þ ß 'à-ö ø-ý À-Ö Ø-Ý
The value you entered appears in the Systems box.
Note:
Be sure to enter the processing code of the system and not the name. This value is entered in update.xml for defining survivor strategies for the single best record (SBR).Do any of the following:
To define additional systems, repeat the above step for each source system that will share information with the master person index application.
To remove a system from the list, highlight the name of that system in the Systems box, and then click Remove.
To remove all systems from the list, click Remove All.
When you have defined all required source systems, click Next.
The Define Deployment Environment window appears.
Continue to "Step 4: Define the Deployment Environment".
Once you define systems, you must specify information about the deployment environment, including the database, match engine, and standardization engine vendors.
Complete "Step 3: Define Source Systems".
On the Define Deployment Environment window, enter the following information:
Database - The type of database being used for the master person index application. You can select MySQL, Oracle, or SQL Server.
Match Engine - The type of match and standardization engine to use for the implementation. Currently, the only option is OHMPI Match Engine.
Date Format - The date format for the master index system. This defines how dates should be entered and how they appear on the MIDM. You can select MM/dd/yyyy, dd/MM/yyyy, or yyyy/MM/dd.
Transaction Mode - An indicator of whether transactions are distributed. Select one of the following options:
XA (across applications), if the transactions will be distributed across multiple applications.
XA (within application only), if the transactions will be distributed just across the master person index application.
Local, if the transactions will not be distributed.
When you have defined the deployment environment fields, click Next.
Continue to "Step 5: Define Parent and Child Objects".
After you define the deployment environment for the master person index application, you can begin to define the structure of the object you want to index. The primary object will be the parent object for any other objects defined. Child objects are not required if all information is stored under the parent object.
You can create new undefined objects, create objects using predefined templates, or use a combination of both methods to create the objects in your enterprise object. Perform any of the following actions to define the objects in the enterprise object.
Complete "Step 4: Define the Deployment Environment" before performing these procedures.
Note:
The names of database constraints are created based on the parent and child object names. Due to database naming restrictions, the length of the parent object name plus the length of any of the child object names must be 21 characters or less. Give the parent object the same name you gave the application earlier in the wizard.When you create undefined objects, you create an empty object with no predefined fields or child objects.
On the Define Enterprise Object window, click Add Primary Object.
The initial node appears on the tree. By default, the name of the field is the same as the name of the application you defined in "Step 2: Name the Master Person Index Application".
Accept the default name by pressing Enter, or type a new name and press Enter.
To create a new child object, select the primary object created above and then click Add Sub Object.
The new child node appears on the tree.
Accept the default name by pressing Enter, or type a new name and press Enter.
Repeat the previous two steps for each child object.
Continue to "Step 6: Define the Fields for Each Object".
When you create objects from a template, secondary objects and fields are predefined. You can modify the objects, fields, and field properties in a template to suit your processing needs.
To create a complete object structure from a template, click Templates on the Define Enterprise Object toolbar, and select the template you want to use.
The objects and fields from the template appear in the tree-view panel in the center of the window.
To create a child object from a template after creating the parent object, right-click the parent object, point to Template, and then select the name of the template you want to use.
The new object and any defined fields appear in the object tree.
If necessary, change the name of the new object by doing the following:
Click twice on the name.
Type the new name.
Press Enter.
Repeat steps 2 and 3 for each child object template you want to create.
Continue to "Step 6: Define the Fields for Each Object".
If you add an object in error, or do not want to use one of the objects in a predefined template, you can delete the object from the structure.
On the Define Enterprise Object window, select the object you want to remove.
Do any of the following:
Right-click in the object tree panel, and then select Delete.
Press the Delete key.
In the wizard toolbar, click Delete.
The object and any fields associated with that object are deleted. If you remove the parent object, all child objects are deleted.
After you define all the parent and child objects for your enterprise object, you need to define the fields in each object. Every field has a set of properties that must be configured before creating the master person index configuration files. If you chose a predefined template to create your objects, be sure to check the properties for all predefined fields to be sure they are configured correctly for your implementation.
After you define the parent and child objects, you can perform any of the following actions to define the fields for those objects.
If you created an empty object in Step 5: Define Parent and Child Objects, you need to create each field that belongs to the object. If you created objects using a predefined template, you can add new fields to the object if needed.
In the object tree panel of the Define Enterprise Object window, do one of the following:
To add the field to the end of the object's field list, select the name of the object to which you want to add a new field and then click Add Field.
To add the field immediately following an existing field, select the field after which you want to add the new field and then click Add Field.
The tree expands and a new field is inserted.
Do one of the following:
To accept the default name, press Enter.
To change the name, type the new name and then press Enter.
For information about field name restrictions, see Master Person Index Wizard Field Name Restrictions.
Continue to "Configuring Field Properties".
When you create a field, a set of default properties is defined for that field. You can modify the property configuration for each field to suit your data processing, storage, and display requirements. After you modify a property value, press Enter to apply the change.
Complete the steps under "Adding a Field".
In the object tree panel of the Define Enterprise Object window, select the field you want to configure.
On the Properties page in the right side of the window, modify the value of any of the properties listed in Master Person Index Wizard General Field Properties.
On the right side of the window, click the MIDM tab, and then modify the value of any of the properties listed in Master Person Index Wizard MIDM Field Properties.
When you have created and configured all of the necessary fields for each object, click Next.
Continue to "Step 7: Generate the Project Files".
If you add a field in error, or do not need one of the predefined fields from a template, you can delete the field.
In the object tree panel of the Define Enterprise Object window, select the field you want to delete.
Right-click in the object tree panel.
From the context menu, select Delete.
The field is removed from the object tree.
Once you have named the application and configured the source systems, deployment environment, objects, and fields for the master index application, you need to generate the configuration files and database scripts. Review the configuration files to be sure the application is set up correctly for your data processing environment.
Note:
Modifying the configuration files is not covered in this document. For instructions on configuring a master person index application, see Oracle Healthcare Master Person Index Configuration Guide (Part Number E18473-01).Verify that all of the information you have entered is complete and correct.
On the Generate Configuration Files window, click Finish.
The configuration files are generated, and are stored in the project configuration folder.
Continue to "Step 8: Review the Configuration Files".
After the wizard is complete, several nodes representing the master person index configuration files are placed in the project for the master person index application. Verify that the configuration files are customized correctly for your implementation. If you need to modify the configuration files, see Oracle Healthcare Master Person Index Configuration Guide (Part Number E18473-01) for information about configuration tasks. For information about the configuration files and configurable options, see Oracle Healthcare Master Person Index Configuration Reference (Part Number E18592-01).
When you create fields in the object structure of the master person index application, you can specify several properties for each field, such as whether the field is required, whether the field will appear as a drop-down menu on the MIDM, whether the field will be used in a blocking query, and so on. There are also some restrictions for how fields can be named and how the properties are defined.
The following sections provide information about the naming restrictions and field properties of the wizard.
When you name the fields in your object structure, be sure to keep the following guidelines in mind to avoid errors when compiling or running the master person index application.
Oracle Healthcare Master Person Index automatically creates a field for each object named objectId, where object is the name of an object or sub-object. You cannot create fields with those names. For example, you cannot create a field named "AddressId" if there is an Address object in the object structure.
If you enter a field name longer than 20 characters, a warning dialog box appears. While most databases can handle names up to at least 30 characters, Oracle Healthcare Master Person Index appends text to the end of fields defined for phonetic encoding or standardization. For fields that will be parsed, normalized, or phonetically encoded, make sure the name of the original field does not exceed 20 characters. Any other field can have a name up to 30 characters long.
In field names, do not use characters or names restricted by Java, XML, or the database platform being used.
The following table lists and describes the properties you can define on the General Properties page of the wizard.
| Property | Description |
|---|---|
| Data Type | The master person index data type of the field. The following data types are supported:
|
| Match Type | The type of matching to be performed against the field, if the field is to be used for match weight generation. You must define at least one field for matching or no weights will be generated.
The match types you specify here define the structure of mefa.xml, including the match string. The match types in mefa.xml might differ from the wizard match types. See Oracle Healthcare Master Person Index Configuration Reference (Part Number E18592-01) for information about the available options for this field and how the wizard match types correlate to mefa.xml types. |
| Blocking | An indicator of whether the field will be used in the blocking query. Specify true to add the field to the blocking query; specify false to omit it from the blocking query. |
| Key Type | An indicator of whether the field is used to identify unique objects. For example, a business index might store several addresses for each business. Each address is assigned an address type and each business can only have one address of each type. Specify true if the field is a unique record identifier, or false if it is not.
Key type fields should also be required fields (see below), unless a combination of fields are specified as key types for an object. Note: It is recommended that each child object contain a key type field, but this is not required. If child objects do not contain one or more key type fields, each enterprise object might accumulate a very large number of child objects depending on the survivor strategy used. |
| Updateable | An indicator of whether the field can be updated from the MIDM and external system messages. Specify true if the field can be updated or false if it cannot. |
| Required | An indicator of whether the field is required in order to save an enterprise object to the database. Specify true if the field is required or false if it is not. If only one key type field is defined for an object, that field should be required. |
| Size | The number of characters allowed in each field. This determines the number of characters allowed in the database columns and defines the maximum number of characters that can be entered into each field on the MIDM. |
| Pattern | The required data pattern for the field. For more information about possible values and using Java patterns, see "Patterns" in the class list for java.util.regex in the Javadocs provided with Java. You might want to define patterns for date, telephone, or SSN fields. Note that for the MIDM, the pattern is further restricted by the value entered for the input mask described in the previous table. If no input mask is specified, all regex patterns are supported. |
| Code Module | The identification code for the drop-down list that appears for this field in the MIDM.
Note: This value must match an entry in the code column of the sbyn_common_header database table and, by default, an entry for the code you enter is created in the Code List database script. You can further customize code lists in the script after completing the wizard. |
| User Code | The processing code for the drop-down list that appears for the fields defined by the Constrained By property. For more information, see the description of the Constrained By property below.
Note: This must match an entry in the code_list column of the sbyn_user_code database table. |
| Constrained By | The name of the field that contains the corresponding User Code value (described above). The User Code and Constrained By properties are used in conjunction to fulfill two purposes. The first purpose is to define a drop-down list for the field that contains the User Code value. The second purpose is to validate the field that contains the Constrained By value against definitions for the field with the User Code value.
For example, if you store non-unique IDs such as credit card numbers or insurance policy numbers, you could create a field named ID Type that has a User Code value of CREDCARD, which is also defined as a code in the sbyn_user_code table. This gives the ID Type field a drop-down list based on the definitions for CREDCARD in the sbyn_user_code table. You could then create a field named ID that would be constrained by the formats defined for the ID Type field. Any IDs you enter would be validated against the value of the ID Type field. |
The following table lists and describes the field properties you can define on the MIDM Field Properties page of the wizard.
| Property | Description |
|---|---|
| Display Name | The name of the field as it will appear on the MIDM. |
| Input Mask | A mask used by the GUI to add punctuation to a field. For example, if users enter the date in the format MMDDYYYY, you can add an input mask to display the dates as MM/DD/YYYY. Use the value mask (described below) to strip the punctuation from the value before storing it in the database.
To define an input mask, enter a character type for each character in the field and place any necessary punctuation between the character types. For example, the input mask for the above date format is DD/DD/DDDD.
Note that the value you enter can further restrict the data pattern for the field (this is the Pattern field property described in Master Person Index Wizard General Field Properties). The following character types can be used. |
| Value Mask | A mask used by the index to strip any extra characters that were added by the input mask (see above). This mask ensures that data is stored in the database in the correct format.
To specify a value mask, type the same value as is entered for the input mask, but type an "x" in place of each punctuation mark. For example, if an SSN field has an input mask of DDD-DD-DDDD, specify a value mask of DDDxDDxDDDD to strip the dashes before storing the SSN. A value mask is not required for date fields. |
| Search Screen | An indicator of whether the field appears on the search windows of the MIDM. Specify true to display the field or false to hide it. |
| Required | An indicator of whether the field must be populated on the search windows of the MIDM when performing a search. This property can only be modified if the Search Screen property is set to true (see above). Specify true to make the field required or specify false to make it optional. You can also specify oneof to create a group of fields of which at least one must be populated to perform a search. (Be sure to specify oneof for each field in the group.)
Tip: If a field is required for a search, the field should also be required for creating a record (by specifyingtrue for the Required property on the Properties page). Otherwise, searches performed from the MIDM could result in no matches even though possible matches exist. |
| Search Result | An indicator of whether the field appears on the search results windows of the MIDM. Specify true to display the field, or false to hide it. |
| Report | An indicator of whether the field appears on the reports generated from the MIDM. Specify true to display the field on the reports; otherwise specify false. |
You can add custom processing to the master person index application by adding your own code to new Java classes in the EJB project for the master person index application. These classes are called custom plug-ins. This ability allows you to tailor how messages are processed by the master person index application. Plug-ins can be used to customize field validations, update policies, match processing logic, and record retrieval, and to create custom components for the master person index application, such as custom phonetic encoders, block pickers, or query builders. You can create as many classes as you need to carry out the custom processes.
The following sections describe custom plug-ins that define custom processing. These are explained more fully in Oracle Healthcare Master Person Index Configuration Reference (Part Number E18592-01).
"Master Person Index Update Policy Plug-ins" - Define custom processing logic to perform against the resulting record of a transaction before it is stored in the database.
"Master Person Index Field Validation Plug-ins" - Define validations to perform against specific fields, such as checking the local ID length and format.
"Master Person Index Field Masking Plug-ins" - Define how the values for sensitive fields are hidden on the MIDM from users who do not have permission to view them.
"Master Index Match Processing Logic Plug-ins" - Define custom logic based on predefined decision points for how records are matched during a transaction.
"Master Person Index Custom Plug-in Exception Processing" - Define how exceptions are handled by the custom plug-ins you create.
For the primary transactions performed by the master person index application, you can define additional custom processing to perform against the record that results from a transaction. The policies you define are invoked by the Update Manager and are applied to the resulting records after they are processed by the survivor calculator. The modifications made to a record by an update policy determine how the record is stored in the database. By creating custom plug-ins, you can create additional Java classes to support the update policies you define.
Update policies are specified in the UpdatePolicy section of update.xml, and there are several different types. Each policy modifies an enterprise object (class com.sun.mdm.index.objects.EnterpriseObject) and must implement com.sun.mdm.index.update.UpdatePolicy, which contains one method, applyUpdatePolicy. The syntax is as follows:
public EnterpriseObject applyUpdatePolicy(EnterpriseObject before, EnterpriseObject after)
This method throws two exceptions:
com.sun.mdm.index.master.UserException
com.sun.mdm.index.objects.exception.ObjectException
The enterprise merge policy defines additional processing to perform after two enterprise objects are merged. The processing defined in this policy acts against the surviving record of the merge. In the EnterpriseMergePolicy element in update.xml, enter the fully qualified name of this custom plug-in.
The enterprise unmerge policy defines additional processing to perform after an unmerge transaction occurs. The processing defined in this policy acts against the surviving record of the merge transaction that was unmerged. In the EnterpriseUnmergePolicy element of update.xml, enter the fully qualified name of this custom plug-in.
The enterprise update policy defines additional processing to perform after a record is updated. In the EnterpriseUpdatePolicy element of update.xml, enter the fully qualified name of this custom plug-in.
The enterprise create policy defines additional processing to perform after a new record is inserted into the master person index database. In the EnterpriseCreatePolicy element of update.xml, enter the fully qualified name of this custom plug-in.
The system merge policy defines additional processing to perform after two system objects are merged. The processing defined in this file acts against the surviving enterprise record of the merge (and not the system record). In the SystemMergePolicy element of update.xml, enter the fully qualified name of this custom plug-in.
The system unmerge policy defines additional processing to perform after system objects are unmerged. The processing defined in this file acts against the surviving enterprise record of the system merge transaction that was unmerged. In the SystemUnmergePolicy element in update.xml, enter the fully qualified name of this custom plug-in.
You can define validations to be performed against certain fields before information is entered into the master person index database. Once you create the custom plug-ins containing the validation logic, enter the name of the plug-in in validation.xml. Follow these guidelines when implementing custom field validators.
The custom validation classes must implement com.sun.mdm.index.objects.validation.ObjectValidator.
The exception thrown is com.sun.mdm.index.objects.validation.exception.ValidationException.
One default field validator, validate-local-id, is provided to validate system and local ID fields before processing data into the database. This is described in Oracle Healthcare Master Person Index Configuration Reference (E18592-01).
There might be instances where you want to mask certain data in records from general users of the Master Index Data Manager and only allow access by administrators. To do this, you can create a custom plug-in that displays asterisks (or other symbols) in place of the field values on the MIDM. Once you define the custom plug-in, specify the name of the custom plug-in Java class in the object-sensitive-plug-in-class element of midm.xml).
You can implement custom plug-ins that customize the way the execute match methods process data into the master person index application. When a record is entered into the master index system, match processing is performed by calling one of the following "execute match" functions from the MasterController class.
executeMatch
executeMatchUpdate
executeMatchDupRecalc
executeMatchUpdateDupRecalc
executeMatchGui (this method is only called by the MIDM)
These methods contain standard logic for processing records through the master person index database, weighting incoming records against existing records, and then using those weights to determine whether to insert a new record or update an existing record. In addition to configuring the match processing logic in master.xml, you can customize certain aspects of the processing logic using custom plug-ins that contain functions found in the ExecuteMatchLogics class.
There are five decision branches where custom logic can be inserted. At specific points in match processing, the execute match methods look for the value of the methods listed below. For more information about the methods, see the Javadocs for the master index. These methods are contained in the ExecuteMatchLogics class in the package com.sun.mdm.index.master. The following methods specify the custom logic.
bypassMatching - Indicates whether to perform the match process on incoming records or to bypass the match process.
disallowAdd - Indicates whether an incoming message can be inserted as a new record.
disallowUpdate - Indicates whether an incoming record can update an existing record.
rejectAssumedMatch - Indicates whether to accept or reject an assumed match of two records.
rejectUpdate - Indicates whether to accept or reject an update to an existing record.
The custom plug-ins you create to define custom execute match logic must extend the ExecuteMatchLogics class. In addition, the following classes must be imported into the custom plug-in.
com.sun.mdm.index.objects.SystemObject
com.sun.mdm.index.objects.EnterpriseObject
com.sun.mdm.index.objects.exception.ObjectException
com.sun.mdm.index.master.ExecuteMatchLogics
com.sun.mdm.index.master.CustomizationException
If you create a custom plug-in that defines custom processing logic for the execute match methods, you must specify those custom plug-ins in master.xml in the master index project. If you create a plug-in for customizing logic in the execute match methods used by the back-end, specify the name of that class in the logic-class element. If you create a plug-in for the MIDM, specify the name of that class in the logic-class-gui element. For example:
<logic-class>com.sun.mdm.index.user.CustomCollaboration</logic-class> <logic-class-gui>com.sun.mdm.index.user.CustomMIDM</logic-class-gui>
For more information about master.xml, see Oracle Healthcare Master Person Index Configuration Reference (E18592-01).
If a custom plug-in throws an exception of the class ObjectException or SystemObjectException, multiple stack traces are logged in the server log file, which can make operational management tasks more difficult. For cases where you do not want stack traces to be logged, configure your custom plug-ins to throw exceptions of the class UserException or one of its derived classes (DataModifiedException or ValidationException). This is useful for user errors on the Master Index Data Manager (MIDM). When one of these exceptions is thrown, no stack trace is entered in the log file but an error message still appears on the MIDM.
For more information about these exception classes, see the Javadocs for Oracle Healthcare Master Person Index.
Oracle Healthcare Master Person Index provides a flexible framework, allowing you to create custom Java classes to plug in to most master person index application components. The following sections provide descriptions of some components for which you can create custom classes to use in your master person index application.
"Master Person Index Survivor Calculator Plug-ins" - Define how the single best record (SBR) is generated.
"Master Person Index Query Builder Plug-ins" - Define how queries are performed against the master person index database.
"Master Person Index Block Picker Plug-ins" - Define how the blocks of fields in a blocking query are selected during a query.
"Master Person Index Pass Controller Plug-ins" - Define how the master person index application determines whether to perform additional match passes against a record.
"Match Engine Plug-ins" - Define logic that connects to a match engine other than the OHMPI Match Engine.
"Standardization Engine Plug-ins" - Define logic that connects to a standardization engine other than that provided by the Master Person Index Standardization Engine.
"Phonetic Encoders Plug-ins for a Master Person Index" - Define logic that connects to phonetic encoders other than those provided.
The survivor calculator determines which field values from the various system records will populate the SBR for the enterprise record. You can create a custom survivor calculator class that selects the surviving field values. Your custom class must implement the survivor calculator interface. Call selectField in com.sun.mdm.index.survivor.SurvivorStrategyInterface to return the SBR value for each field. For more information about the classes and methods to use, see the Javadocs for Oracle Healthcare Master Person Index. The primary classes are contained in the com.sun.mdm.index.survivor package. Enter the fully qualified class path for the custom survivor calculator in update.xml.
The query builder defines the different types of queries that can be used in the master person index application. You can implement custom queries using custom plug-ins. To create a new query builder, you must define a class that extends the base abstract com.sun.mdm.index.querybuilder.QueryBuilder and then specify that class in a query-builder element in query.xml. The exception thrown is com.sun.mdm.index.querybuilder.QueryBuilderException. The following methods must be implemented.
init - This method receives the XML elements after the config element of query.xml so the query builder can read its custom configuration.
getApplicableQueryIds - This method returns an array of string IDs indicating the query objects that can be generated given the available criteria. For example, in the blocking configuration, the unique ID of each block definition is the string that is returned by getApplicableQueryIds.
buildQueryObject - This method constructs the query object based on one of the applicable query IDs provided as an input argument.
For more information about query-related Java classes, see the master person index Javadocs.
The block picker chooses which block definition in the blocking query to use for the next matching pass. You can create a custom block picker class to select query blocks in a customized manner. If you create a custom block picker, specify the fully qualified name of this custom plug-in for the block-picker element of mefa.xml. Follow these guidelines when implementing a custom block picker.
Implement the com.sun.mdm.index.matching.BlockPicker interface to select the blocks in the desired order.
If none of the remaining blocks should be executed, throw a NoBlockApplicableException from the pickBlock method.
The matching process can be executed in multiple stages. After a block is evaluated, the pass controller determines whether the results found are sufficient or if matching should continue by performing another match pass. If you create a custom pass controller, specify the name of the custom Pass Controller in the pass-controller element of mefa.xml. Follow these guidelines when implementing a custom pass controller.
Implement the com.sun.mdm.index.matching.PassController interface to evaluate whether to do another pass or not.
Return true from evalAnotherPass to specify that an additional pass be performed; return false to specify that no additional passes are performed.
You can define classes to connect to a custom match engine instead of the OHMPI Match Engine. Specify the names of the custom classes you create in the matcher-api and matcher-config elements of mefa.xml. Follow these guidelines when implementing custom match engine classes.
Implement the com.sun.mdm.index.matching.MatcherAPI interface to communicate with the match engine.
Implement the com.sun.mdm.index.matching.MatchEngineConfiguration interface to retrieve any configuration values the match engine requires for initialization.
You can also define custom comparison functions to plug in to the OHMPI Match Engine. For more information, see Oracle Healthcare Master Person Index Match Engine Reference (E18470-01).
You can define classes to connect to a custom standardization engine instead of the OHMPI Standardization Engine. Specify the names of the custom classes you create in the standardizer-api and standardizer-config elements of mefa.xml. Follow these guidelines when implementing custom standardization engine classes.
Implement the com.sun.mdm.index.matching.StandardizerAPI interface to communicate with the standardization engine.
Implement the com.sun.mdm.index.matching.StandardizerEngineConfiguration interface to retrieve any configuration values the standardization engine requires for initialization.
You can also define custom standardization rules to plug in to the OHMPI Standardization Engine. For more information, see Oracle Healthcare Master Person Index Standardization Engine Reference (E18471-01).
The master person index application supports several phonetic encoders, and you can define custom classes to implement additional phonetic encoders if needed. Specify the names of the custom classes you create in the encoder-implementation-class element of mefa.xml. When creating a custom phonetic encoder class, implement the com.sun.mdm.index.phonetic.PhoneticEncoder interface.
Custom plug-ins allow you to incorporate custom code into your master person index application. When you create a custom plug-in for a master person index application, you define the package and class names. To incorporate the plug-ins into the master index application, you then specify the fully qualified class name of the class in the appropriate configuration file. For example, if you create a custom plug-in named MergePolicy in the package com.sun.mdm.index.update, the value to enter for the class in update.xml is com.sun.mdm.index.update.MergePolicy.
Note:
You can create custom plug-ins that define custom processing or that define custom components. For additional information about how to implement specific custom-plug ins, see "Using Custom Plug-ins for Custom Transaction Processing" and "Learning About Custom Plug-Ins for Master Person Index Custom Components".You create a custom plug-in by composing Java code in a source file using the NetBeans editor. Create the file in the Source Package folder of the EJB project associated with the master index application. Before you begin, determine the name of the package and class for the plug-in.
In the NetBeans Projects window, expand project_name-ejb (where project_name is the name of the main master index project.
To create a new package for the custom plug-in files, do the following:
Right-click Source Packages, point to New, and then click Java Package.
Enter the package name and location, and then click Finish.
To create the plug-in, do the following for each source file:
Under Source Packages, right-click the name of the package to which the new class will belong.
Point to New, and then click Java Class.
Enter the class name, verify the remaining fields, and then click Finish.
The new file appears in the NetBeans editor.
Create the custom processing rules using Java code.
When you are finished coding, save and close the file.
In the Projects window, right-click the file and then click Compile.
The output and status of the compiling process appears in the bottom panel.
Note:
If you do not compile a custom plug-in file, building the master person index project will compile the files.Specify the name of the custom plug-in in the appropriate master person index configuration file.
Note:
If you modify a custom plug-in, be sure to recompile the file and regenerate the application to incorporate the changes. If the project has already been built, rebuild the project to add the custom plug-in to the EJB JAR file.Before you generate the application, review the configuration files and make any necessary modifications (see Oracle Healthcare Master Person Index Configuration Guide (E18473-01) for more information). Once all modifications to the configuration files are complete and any custom plug-ins are built, generate the master index application to create or update the application components. If you modify any of the configuration files, match and standardization engine files, or custom plug-ins after you generate the application, you need to regenerate the application to update the custom components.
Note:
If any errors occur while compiling the application, they appear in the output panel in the bottom of the window. This window also displays the status of the generate process.Save any configuration changes to the master person index project.
Right-click the master person index application in the Projects window.
Select Generate Master Person Index Files.
The project components are generated. This might take a few minutes.
On the NetBeans toolbar, click Save.
Save any configuration changes to the master person index project.
If you are using the command-line reports, back them up to a different directory. Generating the application overwrites the existing report client.
Right-click the master person index application in the Projects window.
Select Generate, and then click Yes on the dialog box that appears.
The application components are regenerated. This might take a few minutes. The output panel displays the status and any errors that occur.
On the NetBeans toolbar, click Save.