| Oracle® Healthcare Master Person Index User's Guide Release 4.0 E68430-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Healthcare Master Person Index User's Guide Release 4.0 E68430-01 |
|
|
PDF · Mobi · ePub |
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:
Setting Your System for Languages Other Than English to Display Properly
Understanding OHMPI Wizard Name Restrictions and Field Properties
This section provides information for setting your system to display languages other than English properly.
Setting the Language and Region if Different Than English and United States
Setting the UTF-8 Encoding in NetBeans IDE for Simplified Chinese or Languages with Accents
If you plan to use a language other than United States English, set your computer to the desired language and country. For example, if you are using:
Spanish in Mexico, select Mexico
Simplified Chinese in the People's Republic of China, select China
Japanese in Japan, select Japan
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. In our example, we presume you want to use Simplified Chinese.
Click the Regional Options tab.
In the Location section, select China from the drop-down list.
Click OK.
When your computer system is set to Chinese language and you create an OHMPI project, a copy of midm_person_chinese.xml will be created in the project_dir/src/Configuration folder.
Note:
This file (
midm_person_chinese.xml) is based upon the Person template and is translated into Chinese. For projects created with the Person template, you can replace the midm.xml with this file.For languages with accents (Simplified Chinese, Spanish, or Japanese) to display properly in NetBeans, you must add "-J-Dfile.encoding=UTF-8" to the end of "netbeans_default_options" in OracleHealthcareMPIv4_0\netbeans\etc\netbeans.conf. For example:
netbeans_default_options="-J-Dnb.registration.enabled=\"false\" -J-Xmx512m -J-client -J-Xss2m -J-Xms512m -J-XX:PermSize=32m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true -J-Dsun.zip.disableMemoryMapping=true -J-Dfile.encoding=UTF-8"
You must set this option prior to using NetBeans.
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:
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, and opens on the Choose Project window.
Under Categories, select OHMPI.
Under Projects, select Master Person Index Application or IHE Profile Application and then click Next.
Note:
In our example, we selected Master Person Index Application.The Name and Location window appears with default project name and directory paths.
Continue to Step 2: Name and Location.
When you create a new Oracle Healthcare Master Person Index project in NetBeans, the wizard for creating a master person index application automatically appears.
Enter the NetBeans project name and the path where you want to store the project files in the upper portion of the window or accept the defaults.
Select the application server you are using from the drop down list.
If no application servers appear in the list, click Manage.
The Servers window appears.
Click Add Server.
The Add Servers Instance window appears.
Select the Oracle WebLogic Server, and click Next.
Under Server Location, accept the defaults and click Finish.
You are returned to the Servers window with the application server you selected listed under Servers in the left pane.
Click Close.
The Name and Location window reappears.
For IHE Profile only: Select Oracle from the drop-down list.
For IHE Profile application, the HL7 V2 Service Port is populated automatically (the default is 4447. If desired, change the port number.
The Set as Main Project is selected for the Master Person Index application but not for the IHE Profile Application. If you do not want this Master Person Index application to be the main project, deselect the option, and if you want the IHE Profile application to be the main project, select this option.
Click Next.
For an IHE Profile application, this is the final step that you need to perform.
For a Master Person Index application, continue to Step 3: Name Application.
Before you can configure the new master person index application, it is a good practice to give each master person index application a unique name because certain components within the application server are based on this application name. Dependent components include the data source for the JDBC connection and the outbound Topic (if one is used).
Complete Step 2: Name and Location.
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 4: 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.
The source system is the key to your network. If it a hospital (for example, Hospital or Medical Center, the system might be HOS or MC), all of its patient records would be sent into the master person index with a system code/LID of HOS/120210210 or MC/48481234.
The LIDs are specific to the patients. When you have to create data from the Master Index Data Manager (MIDM), every record you enter will need a System/LID. When you click the System Record tab of MIDM (see Oracle Healthcare Master Person Index Data Manager User's Guide for details) and click the Add tab, a drop-down list will have all of the hospital codes you entered. Now, supply the LID for the patient you are entering. If the data comes from the back end, it will have both System and LID as part of the data.
Complete Step 3: Name 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 (for example, "GNH" or "MCT"), 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 inupdate.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 5: Define Deployment Environment.
Once you define the source systems, you must specify information about the deployment environment, including the database and match engine vendors.
Complete Step 4: 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. Select Oracle.
Date and Time Formats - The date and time formats for the master person index system. This defines how date and time must be entered and how they appear on the MIDM. These formats acts as a default format if you do not set the field level format.
Object Date Format: This is the default or application level format used by OHMPI backend for the date data type.
Object Time Format: This is the default or application level format used by OHMPI backend for the timestamp data type.
MIDM Date Format: This is the default or application level format used by MIDM for the date data type.
MIDM Time Format: This is the default or application level format used by MIDM for the timestamp data type.
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.
Click Next.
Continue to Step 6: Define Enterprise Object.
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 user-defined 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 5: Define 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 user-defined objects, you create an empty object with no predefined fields or child objects.
On the Define Enterprise Object window, click the Add Primary Object icon.
The initial node appears on the tree. By default, the name of the parent object is the same as the name of the application you defined in Step 3: Name Application.
Accept the default name by pressing ENTER, or type a new name and press ENTER.
Note:
Oracle recommends that when you define the object structure that the name of the parent object be the same as the application name you created in step 3.To create a new child object, select the primary object created above and then click the Add Sub Object icon.
The new child node appears on the tree.
Highlight the new sub-object and type a user-defined name for it and press ENTER.
Repeat the previous two steps for each child object.
Continue to Defining the Fields for Each Object.
WARNING:
Do not use the following object names because it will cause an error in the create script (due to a clash between the generated object name and a standard OHMPI table) or in the Java code (because the generated method in the ObjectNode extension will clash with an existing method):
SYSTEM
SYSTEMS
SYSTEMOBJECT
ENTERPRISE
TRANSACTION
ASSUMEDMATCH
OVERWRITE
POTENTIALDUPLICATES
AUDIT
MERGE
APPL
COMMON_HEADER
COMMON_DETAIL
SEQ_TABLE
Child
Defining the Fields for Each Object
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.
Note:
If you decide that you would like to use a template as opposed to creating everything from scratch, highlight your primary object and click the X in the tool bar. This deletes the primary object you are working on. You can select the Add Solution icon, and perform one of the following:Highlight Generic and then select Person or Company
Highlight Provider and then select Organization or Individual
Highlight Patient and then select USPatient, UKPatient, or AUPatient
See Creating Objects from a Template for additional information.
Caution:
Delete primary objects, sub-objects, and fields carefully, for once deleted you cannot retrieve them.After you define the parent and child objects, you can perform any of the following actions to define the fields for those objects.
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.
Complete Creating User-defined Objects.
In the object tree panel of the Define Enterprise Object window, perform 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.
Perform 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 OHMPI 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.
Note:
If you do not press ENTER, you will lose the name you typed.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 panel 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.
When you create objects from a template, secondary objects and fields are predefined.
To create a complete object structure from a template, click the Add Solution icon on the Define Enterprise Object toolbar, and perform one of the following:
Highlight Generic and then select Person or Company
Highlight Provider and then select Organization or Individual
Highlight Patient and then select USPatient, UKPatient, or AUPatient
For more details about the Provider and the Patient template solutions, see the following guides: Oracle Healthcare Master Person Index Provider Index User's Guide, Oracle Healthcare Master Person Index United States Patient Solution User's Guide, Oracle Healthcare Master Person Index United Kingdom Patient Solution User's Guide, or the Oracle Healthcare Master Person Index Australia Patient Solution User's Guide.
The Provider and the Patient template solutions are pre-set and you cannot edit or configure them until after you have generated the application file.
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.
Note:
Once you delete an object, it is gone and you cannot retrieve them.Once you have named the application and configured the source systems, deployment environment, objects, and fields for the master person 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.Complete Step 6: Define Enterprise Object.
On the Generate Project Files window, verify that all of the information you have entered is complete and correct.
If desired, generate the remaining Master Person Index application files by selecting the appropriate box, and then click Finish.
Note:
Although you can generate the remaining Master Person Index application files at this time, it is not necessary to do this now as you can also generate them when your project appears in NetBeans. Waiting may be the better option, for then you can configure your files in NetBeans before generating them. If you generate them at this time, you will have to generate them a second time after you complete the configuration process.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 for information about configuration tasks. For information about the configuration files and configurable options, see Oracle Healthcare Master Person Index Configuration Reference.
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, or whether the field will be used in a blocking query. 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 |
| 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: Oracle recommends 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. |
| Field 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.
Labeled "Field Size" in the MIDM, it is "<size>" in the XML files. |
| 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 following table. If no input mask is specified, all regular expression 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 |
| 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 |
| 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 |
Footnote 1 If you select char when working in the OHMPI wizard, the NetBeans Editor, or the Configuration Editor, this selection will limit the number of characters a field can contain to 1 character (for example, the Field Size is now limited to a 1 character entry).
Footnote 2 If you select boolean when working in the OHMPI wizard, the NetBeans Editor, or the Configuration Editor, this selection will limit you to two one-byte values in certain fields. For example, fields that require a "True" or "False" response will now be restricted to a "T" or "F" response.
Footnote 3 If you select blob when working in the OHMPI wizard, the NetBeans Editor, or the Configuration Editor, this selection will gray out all the other fields, preventing you from setting any values in them. However, in the database, all these fields will now have unlimited space for any type of free-form entry. Be aware that there are two limiting factors when you choose blob: 1) the MIDM will not be available to view your entries in the fields, which will never appear in the MIDM, and 2) for you to view or change the values of the affected fields you must do so by accessing your database from the back end.
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 OHMPI Wizard General Field Properties). |
| 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 specifying true 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.
OHMPI Update Policy Plug-ins define custom processing logic to perform against the resulting record of a transaction before it is stored in the database.
OHMPI Field Validation Plug-ins define validations to perform against specific fields, such as checking the local ID length and format.
OHMPI 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.
OHMPI Processing Logic Plug-ins define custom logic based on predefined decision points for how records are matched during a transaction.
OHMPI Custom Plug-in Exception Processing defines 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 person index. These methods are contained in the ExecuteMatchLogics class in the package com.sun.mdm.index.master. For information about where the decision points are reached in the processing logic and how to change the logic, see Oracle Healthcare Master Person Index Message Processing Reference. 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 the Oracle Healthcare Master Person Index Configuration Reference.
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.
OHMPI Survivor Calculator Plug-ins define how the single best record (SBR) is generated.
OHMPI Query Builder Plug-ins define how queries are performed against the master person index database.
OHMPI Block Picker Plug-ins define how the blocks of fields in a blocking query are selected during a query.
OHMPI 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 an OHMPI 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 OHMPI 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 should be 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 (E).
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.
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 OHMPI 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 person 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 Person Index Application or the IHE Profile Application 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.
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 Package.
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 your Master Person Index project, review the configuration files and make any necessary modifications. See Oracle Healthcare Master Person Index Configuration Guide (E25247-01) for more information. Once all modifications to the configuration files are complete and any custom plug-ins are built, generate your Master Person Index or IHE Profile project to create or update the project components. If you modify any of the configuration files, match and standardization engine files, or custom plug-ins after you generate the project, you need to regenerate the project to update the custom components.
Note:
If any errors occur while compiling the project, 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 or the IHE Profile project.
Note:
While you can perform many configuration changes on a Master Person Index project, you are limited with the number of changes you can perform on an IHE Profile project.Right-click the Master Person Index or the IHE Profile project in the Projects pane and then select Clean and Build.
The project files are cleaned and built. This might take a few minutes.
Right-click the Master Person Index or the IHE Profile project in the Projects pane and then select Generate Master Index Files or Generate Table Compression Scripts. For more information on selecting Generate Table Compression Scripts, see To Generate Table Compression Scripts.
The project components are generated. This might take a few minutes.
Note:
NetBeans automatically saves your project at the completion a successful build.The database compression helps to reduce the resources and the costs of managing large data volumes. You can optionally create the database scripts with table compression enabled. Before you do so, make sure your database license includes the Oracle Advanced compression options.
OHMPI compresses all the database tables based on the definition in object.xml of the MPI project in addition to the OHMPI specific tables.
OHMPI provides Advanced compression for Oracle Database 12c and OLTP compression for Oracle Database 11g.
To enable the table compression:
Right-click the Master Person Index or the IHE Profile project in the Projects pane and then select Generate Table Compression Scripts to generate create.sql script with table compression or blob deduplication for Oracle Database 11g or 12c.
The Choose Required Options dialog box appears.
Select the appropriate option for the Oracle database version.
Select the BLOB Deduplication check box to enable BLOB deduplication.
Click Generate Files.
For more information, see Oracle Database Administrator's Guide and Oracle Database SecureFiles and Large Objects Developer's Guide.
Projects which are created from the earlier OHMPI releases include some outdated schema or library files that do not have the latest and additional features. When you update such projects, the Update function lists all the configuration schema and library files that you must update.
Right-click the Master Person Index or the IHE Profile project in the Projects pane and then select Update.
The Update MPI Project dialog box appears listing all outdated files. By default, check boxes for all files are selected. You can unselect the Will be updated check box for the files which you do not want to update.
Note:
You must back up the original files before updating the project.Click OK.
Save any configuration changes to the Master Person Index or the IHE Profile 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 or the IHE Profile project in the Projects pane and then select Clean and Build.
The project files are cleaned and built. This might take a few minutes.
Right-click the Master Person Index or the IHE Profile project in the Projects pane and then select Generate Master Index Files or Generate Table Compression Scripts. For more information on selecting Generate Table Compression Scripts, see To Generate Table Compression Scripts.
The application components are regenerated. This might take a few minutes. The output panel displays the status and any errors that occur.
Note:
NetBeans automatically saves your project at the completion a successful build.The wizard provides a simple procedure for you to upgrade any existing 3.x master index application which is created by the 3.x OHMPI release to the 4.0 release. The upgrade does not impact any existing data model schema, settings and configurations and database. This section provides instructions for upgrading any existing 3.x project using the wizard. To upgrade the existing 3.x project, perform the following steps:
Open the project.
Note:
Do not modify any existing data model, settings, and databases.On the NetBeans toolbar, click Open Project.
Browse to the folder where the project is contained.
Select the Open Required Projects check box and select Open Project.
When project opens, the "Resolve project problems" warning appears.
Click Resolve Problems and follow instructions to include the junit library.
Clean up the project artifacts that need to be regenerated by the new wizard.
Right-click on the project in the NetBeans projects explorer, and select Clean.
Update the project. For information, see To Update a Project.
Note:
You must update the following files:BusinessName/lib/standardizer-sbme-impl.jar
BusinessName/instance/Generic/lib/standardizer-sbme-generic-businessname.jar
Address/lib/standardizer-sbme-impl.jar
Regenerate the project artifacts using the new wizard.
Right-click on the project in the NetBeans projects explorer, and select Generate Master Index Files or Generate Table Compression Scripts. For more information on selecting Generate Table Compression Scripts, see To Generate Table Compression Scripts.
Rebuild the project in order to automatically include all the release 4.0 artifacts.
Right-click on the project in the NetBeans projects explorer, and select Build.
Deploy the upgraded application to the WebLogic Server 12c.
Note:
You can use the existing database which runs for the existing 3.x application.Configure the application server.
Configure connectivity.
Deploy the build.
For any existing 3.x profiler, cleanser and loader, you must follow the instructions to regenerate the profiler, cleanser, and loader using the release 4.0 wizard. For information, see Oracle Healthcare Master Person Index Loading the Initial Data Set User's Guide. No changes on the existing configuration files are required to work with the upgraded profiler, cleanser, and loader.
|
 Copyright © 2011, 2016, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|