The following topics describe the default projects provided with Sun Master Patient Index. If you want to get started with Sun Master Patient Index right away, you can skip this section and go right to Implementing the Default Projects.
Sun Master Patient Index includes one server project and two client projects, one that processes data through a Collaboration and one that processes data through a Business Process. Two small data files are provided with the Java CAPS documentation at http://developers.sun.com/docs/javacaps/tutorials/index.jspso you can immediately enter data through either client project. Once Sun Master Patient Index is running, you can create additional data files to enter data through the client projects, and you can create and modify data through the EDM.
The projects are described in the following topics:
The server project defines an enterprise-wide master patient index that processes and stores information about the patients in a healthcare organization. The Sun Match Engine is used to standardize data and provide matching weights. The Connectivity Map defines the Sun Master Patient Index application and also defines the database connection pool using an Oracle Adapter, which is configured to connect to the database using a thin client JDBC connection, or a SQL Server Adapter (depending on which version of Sun Master Patient Index you installed). The server project includes a method OTD that contains the methods used in the client projects’ Java Collaboration and Business Process. It also includes an outbound OTD that you can use with a JMS Topic to broadcast messages processed by Sun Master Patient Index back out to external systems.
JMS Topics are not configured in the default Connectivity Maps and the process is not described in this tutorial. For more information and instructions, see Defining Connectivity Components for a Master Index (Repository) in Configuring Master Index (Repository) Connectivity and Environments.
The object structure for the Sun Master Patient Index application is based on standard patient data and includes information essential to identifying a patient, such as names, date of birth, national identifiers, and so on. The Parent object, named Person, contains demographic and identifying information. Child objects contain address, phone, alias, auxiliary ID, and comment information, including parsed and phonetic versions of the name and street address fields.
Four different types of queries are defined in the Candidate Select file: a basic alphanumeric query, a phonetic version of the alphanumeric query, a blocking query to use for potential duplicate processing, and a blocking query to use for phonetic searches from the EDM. The blocking queries contain the following data blocks, which you can modify.
Phonetic first and last names
Social Security Number
Phonetic first name, date of birth, and gender
Phonetic last and maiden names
Phonetic first and last alias names
House number and phonetic street name (EDM query only)
Phonetic street name and phonetic last name (EDM query only)
The server project is configured to parse, normalize, and phonetically encode person names and street address names. The fields that store the modified data are defined in the database, but do not appear on the EDM. The following sections provide a general overview of how standardization and matching are configured. You can modify the configuration to obtain different results.
By default, each name stored in the master index is phonetically encoded, and a patient’s primary and alias names are normalized prior to phonetic encoding. Normalization is based on the United States domain. The following fields are included in the object structure to store the normalized data.
Person.StdFirstName
Person.StdMiddleName
Person.StdLastName
Alias.StdFirstName
Alias.StdMiddleName
Alias.StdLastName
The following fields are included in the object structure to store the phonetic codes for each name.
Person.FnamePhoneticCode (patient’s first name)
Person.LnamePhoneticCode (patient’s last name)
Person.MnamePhoneticCode (patient’s middle name)
Person.MotherMNPhoneticCode (mother’s maiden name)
Person.MaidenPhoneticCode (patient’s maiden name)
Person.SpousePhoneticCode (spouse’s name)
Person.MotherPhoneticCode (mother’s name)
Person.FatherPhoneticCode (father’s name)
Addresses are parsed and standardized based on the United States domain. The default value, used when no domain is specified, is the United States. Addresses are parsed into the following components (with the actual field name in parentheses).
House number, rural route identifier, P.O. box number (Address.HouseNumber)
Match street name, rural route descriptor, P.O. box descriptor (Address.StreetName)
Street direction (Address.StreetDir)
Street type (Address.StreetType)
After being parsed, the street name is also phonetically encoded. The phonetic version is stored in the Address.StreetNamePhoneticCode field.
The default match string consists of the following fields, which are considered standard for matching on person information.
Person.StdFirstName
Person.StdLastName
Person.SSN
Person.DOB
Person.Gender
The following table lists the default configuration for the Threshold file of the sample server project. The query builder specified for matching is the query named “BLOCKER-SEARCH” in the Candidate Select file.
Table 1 Default Threshold Parameter Configuration
Parameter |
Default Configuration |
---|---|
Update Mode |
Pessimistic |
Merged Record Update |
Disabled |
One Exact Match |
False |
Same System Match |
True |
Duplicate Threshold |
7.25 |
Match Threshold |
29.0 |
EUID Length |
10 |
Checksum Length |
0 (checksum values are not used) |
Chunk Size |
1000 |
In addition to the standard EUID and System/Local ID lookups, three additional searches are defined for the EDM: an alphanumeric search, a phonetic search, and a Social Security Number lookup. The following criteria fields are defined for alphanumeric searches:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The following fields are defined for phonetic searches:
|
|
|
|
|
|
|
|
See Query Configuration for the possible combinations allowed for the phonetic search.
The DOB field is defined to support range searching and includes a “From” field and a “To” field on the EDM search pages, allowing you to supply the range of values on which to search.
In the default configuration, the Search page is the first to appear when you log on to the EDM, all standard reports are enabled, and the audit log is disabled. If you want to view the audit log for the sample project, be sure to enable it before generating the project. Field masking is enabled for the SSN, Maiden Name, VIP Flag fields as well as certain address and telephone fields.
Sun Master Patient Index includes a Collaboration client project that shares information between the Sun Master Patient Index application and two File Adapters (one sending data to Sun Master Patient Index and one receiving data from Sun Master Patient Index). The client reads the sample data from the input file through the inbound File Adapter, unmarshals the data into the Sun Master Patient Index OTD (eIndexInput), and copies each field value of the OTD into the class variable SystemPerson. The variable is then passed to the Java method executeMatch, which processes the new data by comparing it against existing Sun Master Patient Index records, assigning matching weights between records, and determining whether the incoming data is a new record or an update to an existing record.
After the message is processed, the new or updated record is sent to the outbound File Adapter, along with the EUID of the new or updated record and an indicator of whether the record was added, updated, merged, and so on. You can call additional Sun Master Patient Index methods in the Collaboration to customize the processing logic. To view the available methods, right-click Person_1 in the left pane of the Business Rules Designer and then select Browse This Type.
The Sun Master Patient Index sample provides a Business Process client project that shares information through a Business Process. This project uses the same processing logic as the Collaboration client project, using executeMatch to process messages into the Sun Master Patient Index application and returning the EUID of the affected record as well as the results code.
Standard result codes include the following. Additional results codes can be returned if you are using custom processing for executeMatch.
1 - A new record was added to Sun Master Patient Index.
2 - An update was performed because a matching system and local ID pair exists in Sun Master Patient Index.
3 - An assumed match was found.
This project unmarshals the data into the eIndexBPInput OTD. You can call additional Sun Master Patient Index methods in the Business Process to customize the processing logic. Available methods are listed under the Person node of the Sun Master Patient Index server project.