The topics listed here provide procedures, conceptual information, and reference information for using the Patient Enterprise Data Manager (Patient EDM) to monitor and maintain data for master patient index applications.
What You Need to Know
These topics provide information you should to know before you start to perform specific tasks using the Patient EDM.
What You Need to Do
These topics provide instructions on the tasks you can perform using the Patient EDM to monitor and maintain data in Sun Master Patient Index.
Logging On and Off
Searching for Patients
Performing a Social Security Number Lookup on the Patient EDM
Performing an Advanced Alphanumeric Lookup on the Patient EDM
Viewing Patient Profiles
Comparing Patient Information
Adding and Updating Patient Information
Changing the Status
Managing Potential Duplicates
Managing Assumed Matches
Combining or Separating Patient Information
Running Reports
More Information
These topics provide additional information to help you perform the above tasks on the Patient EDM. These topics are primarily descriptions of the fields and certain field values you see on the Patient EDM windows.
Several topics provide information and instructions for implementing and using a Repository-based master index application. For a complete list of topics related to working with Sun Master Patient Index (Repository), see Related Topics in Developing Sun Master Patient Indexes.
The Patient EDM is a web-based interface that allows you to access, monitor, and maintain the data stored by Sun Master Patient Index. The Patient EDM provides the ability to search for, add, update, deactivate, merge, unmerge, and compare patient profiles. You can also view and correct potential duplicate profiles, view transaction histories, view an audit log, and print reports.
The Patient EDM is your primary tool to view and maintain the data stored in the master index database and cross-referenced by a master index application.
Sun Master Patient Index is an enterprise-wide master index application built using the Sun Master Index platform and provides all of the functionality of a Sun master index application. Sun Master Patient Index creates a single, consistent view of all patient data by providing an automatic, common identification process regardless of the location or system from which the data originates. Patient profiles from various locations are cross-referenced using an enterprise-wide unique identifier (EUID) assigned to each profile by Sun Master Patient Index. By creating EUIDs, Sun Master Patient Index can identify many types of participants, such as patients, customers, employees, contacts, and so on.
The identification and demographic information for all patients is centralized in one shared index. Sun Master Patient Index is designed specifically to support scattered business locations and disparate information systems across an enterprise, as well as various applications from multiple vendors. Sun Master Patient Index makes it easy to find information that was previously scattered among multiple systems.
The following topics describe the features and functions of Sun Master Patient Index.
The components of Sun Master Patient Index are highly configurable, allowing the application to be customized for your specific data processing needs. Primary features ofSun Master Patient Index include the following:
Centralized Information – Sun Master Patient Index maintains a centralized database, enabling the integration of data records throughout the enterprise while allowing local systems to continue operating independently. The index stores copies of local system records and the single best record (SBR), which represents the most accurate and complete data for each patient. This database is the central location of all patient information and identifiers, and it is accessible throughout the enterprise. Records from various systems are cross-referenced using the EUID assigned by Sun Master Patient Index to each patient profile.
Configurability – Before deploying Sun Master Patient Index, you can customize the components and processing capabilities of the system. The configurable components include:
The types of objects to index
The types of data stored in Sun Master Patient Index
The standardization and match engines to use
Matching, standardization, and phonetic conversion rules
Survivorship and weighting rules for determining the SBR
The types of queries available
How queries are blocked, or grouped, for match processing
Patient EDM appearance
Searches available to the Patient EDM
Local ID validation rules
Cross-referencing – Sun Master Patient Index is a global cross-referencing application, matching profiles across disparate source systems and simplifying the process of sharing data between systems. Sun Master Patient Index uses the local identifiers assigned by your existing systems as a reference, allowing you to maintain your current systems and practices.
Data Cleansing – Sun Master Patient Index uses configurable matching algorithm logic to uniquely identify patient profiles and to identify duplicate and potential duplicate profiles. Sun Master Patient Index provides the ability to easily merge or resolve duplicates, and can be configured to automatically match profiles that are found to be duplicates of one another.
Data Updates – Sun Master Patient Index provides the ability to add, update, deactivate, merge, and delete data in the database tables through messages received from external systems or the Patient EDM. Messages received from external systems and the Patient EDM are checked for potential duplicates during processing.
Updates to External Systems – The Sun Enterprise Service Bus provides the master index application with the ability to publish updated information to external systems, provided the external systems can accept incoming messages. This is handled through a JMS Topic to which the master index application publishes XML messages that contain the updates.
Identification – Sun Master Patient Index employs configurable probabilistic matching technology. This technology uses a matching algorithm to formulate an effective statistical measure of how closely profiles match. Using a state-of-the-art algorithm in real-time mode and establishing a common method of locating patientprofiles, Sun Master Patient Index consistently and precisely identifies objects within an enterprise.
Integration – Relying on the Sun Enterprise Service Bus, Sun Master Patient Index provides the power and flexibility to identify, route, and transform data to and from any system or application throughout your business enterprise. It can accept incoming transactions and distribute updates to any external system, providing seamless integration with the systems in your enterprise.
Matching Algorithm – Sun Master Patient Index is designed to use the Sun Match Engine or a custom matching algorithm to provide a matching probability weight between patient profiles. The Sun Match Engine provides the flexibility to create user-defined matching thresholds, which control how potential duplicates and automatic merges are determined.
Unique Identifier – Sun Master Patient Index assigns an enterprise-wide unique identifier (EUID) to each object added to the database. The index uses the EUID to cross-reference the local IDs assigned to each patient by the various computer systems throughout the enterprise.
While Sun Master Patient Index cleanses data automatically as it is entered through external system messages or the Patient EDM, there are instances where it cannot be determined automatically whether two patient profiles truly match one another. In these cases, manual review through the Patient EDM is needed to verify the status of the two profiles and then to possibly join two potential duplicate profiles or separate two profiles that were automatically joined. The Patient EDM provides additional functions to help you maintain the data you store. Using the Patient EDM, you can perform the following activities.
View a Patient’s History – The system provides a complete transaction history of each patient profile by recording all changes to each patient’s data. This allows you to view before and after images of a profile for each change made. The table also records the user ID of the person who made the changes. This history is maintained for both the local system records and the SBR.
Search for Patient Profiles – Using the Patient EDM, you can search for specific patients or sets of patients. The Patient EDM allows you to perform different types of searches using different combinations of data elements, and returns a list of potential matches to your search criteria. Sun Master Patient Index also parses address components, so you can search for a patient profile by their street address. For certain searches, the results are assigned a matching weight that indicates the probability of a match.
Maintain Patient Data – The Patient EDM supports all the necessary features for maintaining patient profiles. It allows you to add new profiles; view, update, deactivate, or reactivate existing profiles; and compare profiles for similarities and differences. You can also view each local system record associated with an SBR.
Compare Patient Data – The Patient EDM allows you to compare two patient profiles in a side-by-side comparison so you can evaluate their differences or similarities. You can also compare different objects within one patient profile in the same comparison view. For example, you can compare the profile’s SBR with a record from System A; or you can compare a profile’s record from System A with its record from System B.
View and Resolve Potential Duplicates – Using algorithm matching logic,Sun Master Patient Index has the ability to identify potential duplicate profiles and the Patient EDM provides the ability to correct the duplicate profiles. Profiles that are potential duplicates can be viewed online in a side-by-side comparison. Potential duplication is resolved by either merging the profiles in question or removing their potential duplicate flags.
Merge and Unmerge Profiles – You can compare potential duplicate profiles and then merge the profiles if you find them to be actual duplicates of one another. Using the merge feature, you can determine which profile to retain as the active profile. The Patient EDM also allows you to merge system records between patient profiles and to specify which information from each system record to preserve in the resulting profile. If two patient profiles or system records are merged in error, you can unmerge them, returning the information to the original records. You can also view a history of merges for a profile by viewing its merge tree.
Add and View Comments – You can add free-text comments to a patient profile or system record to provide additional information about the patient that might not be included in the standard fields.
Audit Log – The system administrator can specify that a log be maintained of each instance that patient data is accessed from the Patient EDM. This log provides information such as the user ID of the user who accessed the data, the type of action that was performed against the data, and the date and time of access. From the audit log, you can also view a transaction history for each transaction that caused an audit log entry.
Security – Security is provided through the application server and includes basic access to the database through user login IDs and passwords, as well as access to specific functions and actions of Sun Master Patient Index. Access can be restricted by functions, actions within functions, data element, and user ID.
All information about a patient is stored in a patient profile. The following topics provide information about the structure of a patient profile.
A patient profile, also known as an enterprise object, is a set of information that describes characteristics of an individual patient in Sun Master Patient Index. Figure 1 illustrates an EUID tree for a patient profile, which shows all components of a profile.
A patient profile contains two types of records:
System Records – A system record is a set of information from an external system that shares data with Sun Master Patient Index. A patient profile might contain several system records.
Single Best Record – The single best record (SBR) is a set of information derived from the best information from each system record in a patient profile (as determined by the survivor calculator). Each patient profile has only one SBR.
System records are different from the SBR in that each system record contains a system and local ID pair and only contains data from a specific system. The information in the system records of a patient profile is used to determine the best value for the SBR in that profile. If a patient profile only contains one system record, the SBR will be identical to that system record. However, if a patient profile contains multiple system records, the SBR might be identical to one system record but will more likely include a combination of information from all system records. Certain actions against a system record will cause the SBR to be changed, such as updating, deactivating, or merging a system record. Each active patient profile must have at least one active system record. If all system records in a profile are deactivated, then the entire profile will also be deactivated.
The single best record (SBR) for a patient profile is made up of a combination of information from all active system records associated with that patient profile. The SBR represents the information that is determined by Sun Master Patient Index to be the most reliable and current of all system records in a patient profile. The SBR is dynamic and is recalculated each time an update is made to an associated system record, a merge or unmerge affects the patient profile, or a system record in the profile is deactivated or reactivated. You can use the overwrite capability of the Patient EDM to update the SBR directly or you can update a system record and allow the survivor calculator to determine how to update the SBR (for more information, see Survivor Calculator).
If you use the overwrite capability to update a field, that field remains locked and cannot be updated by changes to system records until the field is unlocked. For more information about the overwrite function and locked fields, see Updating the SBR and Updating System Records.
The survivor calculator determines which information from each system record in a patient profile is stored in the SBR for that profile. The calculator uses information defined by the system administrator to calculate the SBR. By default, the survivor calculator uses a weighted strategy for most fields, using the relative reliability assigned to each system in combination with the reliability given to the most recently updated value.
For some fields, such as alias and auxiliary IDs, a union strategy is typically used. This means that all unique alias names and auxiliary IDs from all systems are included in the SBR. For detailed information about the survivor calculator and configuring the survival strategy, see Configuring Sun Master Indexes (Repository) and Understanding Sun Master Index Configuration Options (Repository).
In Sun Master Patient Index, a patient profile or system record can have three different statuses: active, inactive, or merged. The Patient EDM uses special characters in the EUID tree to indicate profiles or system records that have a status other than active. The Patient EDM also uses indicators in the EUID tree to denote the type of profile you are viewing when a side-by-side comparison of the same EUID is displayed. For example, when a transaction history is displayed, the previous image of the profile appears in parentheses. Table 1 lists and describes each indicator.
Table 1 Patient Profile Indicators
Indicator |
Status |
---|---|
No indicator. |
The status of the profile or system record is active. |
The status of the profile or system record is inactive. For example, EUID=~1001002135. In addition to the tilde, the EUID appears in fuchsia typeface. |
|
The status of the profile or system record is merged. For example, EUID=*1001002135. In addition to the asterisk, the EUID appears in brown typeface. Note – When an asterisk appears next to a profile on the Transaction History Search Results page, it means the transaction history could not be accessed. |
|
Brackets indicate that the records displayed are the same version of the same profile. This is used on the Comparison page when comparing different components of the same profile. The EUID on the left appears in brackets. For example, EUID=[1001002135]. |
|
When a transaction or merge history is displayed, the EUID representing the previous version of the displayed profile appears in parentheses. This profile represents the status of the profile before the transaction or merge occurred. For example, EUID=(1001002135). |
In Sun Master Patient Index, each system record and SBR in a patient profile contains a set of sub-objects that store different types of information about the patient. Generally, a record contains a parent object and several child objects. By default, the parent object is a person object, which is associated with these child objects: address, telephone, alias, auxiliary ID, and comment. A record can have only one parent object, but can have multiple child objects and multiple instances of each child object with each instance being identified by a unique field. For example, a record can only contain one patient name and social security number (contained in the parent object), but could have multiple addresses and telephone numbers (contained in child objects). Each address must be of a different type, such as a home address, billing address, or mailing address.
The person object is the primary object in a system record or SBR, and stores demographic information about a patient. Each record can have only one person object. By default, the person object of the SBR contains the information from each system that is determined to be the best information by the survivor calculator. Certain fields must be entered in the person object in order to save a patient profile. By default, these fields include first and last names, date of birth, and gender.
Address objects store a patient’s address information in a system record or SBR. Each address is identified by an address type. Each system record or SBR can store multiple addresses, but can only store one address of each type. For example, a record can have a home and a business address, but cannot have two home addresses. By default, the survivor calculator determines which system record addresses to store in the SBR by looking at all system record addresses. If each address type is unique, then all addresses are included in the SBR. If there are multiple addresses of one type, the survivor calculator determines which address to store in the SBR.
Phone objects store a patient’s telephone numbers in a system record or SBR. Each telephone number is identified by a phone type. Each system record or SBR can store multiple telephone numbers, but can only store one number of each type. For example, a record can have a home and a cellular telephone number, but cannot have two home telephone numbers. By default, the survivor calculator determines which system record telephone numbers to store in the SBR by looking at all system record numbers. If each phone type is unique, then all telephone numbers are included in the SBR. If there are multiple telephone numbers of one type, the survivor calculator determines which number to store in the SBR.
Alias objects store nicknames, maiden names, or any other names used by a patient. Each system record or SBR can have multiple alias names. By default, all unique alias names from each system record in a patient profile are included in the SBR. If two system records contain identical alias objects, then only one of those objects is stored in the SBR.
AuxId objects store a patient’s auxiliary IDs in a system record or SBR. Auxiliary IDs are identifiers assigned to a patient that are not necessarily unique to each patient. For example, they can be used to store a credit card number for a joint credit card, an account number for a joint checking account, or an insurance policy number for a policy that covers all members of a family. Each system record or SBR can store multiple auxiliary IDs. By default, all auxiliary IDs from each system record in a patient profile are included in the SBR. If two system records contain identical auxiliary ID objects, then only one of those objects is stored in the SBR.
Additional information about patients appears in the form of comments. Comment objects contain free-form fields in which you can enter information about a patient that does not appear in standard Patient EDM fields. Each comment you add to a patient profile must include a comment code that is unique for the patient profile. This code is used to identify the comment. By default, the survivor calculator determines which system record comments to store in the SBR by looking at all system record comments. If each comment type is unique, then all comments are included in the SBR. If there are multiple comments of one type, the survivor calculator determines which comment to store in the SBR.
Comments can be used to store information about such issues as resolving or merging potential duplicates or reasons for merging or unmerging profiles. They can also be used to store additional information about a patient, such as recording information from a conversation with the patient.
Each patient profile in Sun Master Patient Index is assigned a unique identification number in addition to the local IDs assigned by individual systems. Each patient has one unique identification number throughout your organization, and a unique identification number within each system with which they are registered. Patients might also have several auxiliary IDs, meaning that they share these identification numbers with other patients.
Every patient profile in the master index application is assigned an enterprise-wide unique identification number. This number is the same for that patient regardless of the system from which the patient information originates. This number is called the enterprise-wide unique identifier (EUID) and is used to cross-reference patient profiles in order to accurately identify the patients throughout your organization.
A local ID is a unique local identification number that is assigned to a patient in each system at which they are registered. These numbers are assigned using a numbering system unique to each local system, and are used internally by the systems to identify each patient. Sun Master Patient Index uses a patient’s EUID to cross-reference their local IDs in different systems. Note that the name of the Local ID field is configurable and might be different for your implementation.
An auxiliary ID is an identification code that does not necessarily uniquely identify a single patient within the database, but might identify a group of patients. For example, if a family shares the same account or insurance policy, every family member would have the same identification code for that account or policy.
The Patient EDM is a web-based application, which means you access the application through an internet browser. The Patient EDM uses standard web-based features, such as hyperlinks, data fields, and action buttons, to help you enter information and navigate through the different Patient EDM pages. The following topics provide basic information about the design of the Patient EDM and logging in to and out of the application.
Before you can use the Patient EDM, you must first log in to the application by entering the correct URL in your web browser, and then specifying your login ID and password. Make sure you have a user ID and password for Sun Master Patient Index before logging in. The application server running Sun Master Patient Index must be started before you can log in to the Patient EDM.
The URL for the Patient EDM is:
http://host:port/app_nameedm |
where
host is the name of the server machine.
port is the port number used by the Patient EDM.
app_name is the name of the Sun Master Patient Index application (typically, app_name is Person) .
The port number for the Sun Java System Application Server is listed in the domain.xml file in the http-listener element (8080 by default). The domain.xml file is located in app_server_home\domains\domain_name\config.
Launch a web browser (Internet Explorer 6.0 with SP1 or later).
In the Address field, enter the appropriate URL.
The Login page appears.
Enter your login ID and password in the appropriate fields.
Click Login.
The initial page appears. (By default, the initial page is the Search page, but this is configurable.)
After a certain period of inactivity, the Patient EDM automatically logs off and returns you to the Login page when you try to perform an activity on the Patient EDM. Simply reenter your user name and password to access the Patient EDM again. The system administrator can set the inactivity period at the server level in the session-timeout element of default-web.xml (in logicalhost_home\is\domains\domain_name\config) or at the application level in web.xml in the Sun Master Patient Index application .war file (located in the deployment .ear file) or in the deployment folder itself. The application level overrides any values set at the server level. The default inactivity period is 30 minutes.
Security for the Patient EDM is defined at the function level. You might not be able to perform all the functions described in this guide depending on the security permissions you are assigned. For more information about functions you can perform, see your system administrator.
The Patient EDM provides hyperlinks and command buttons to help you access and move through the Patient EDM pages. When you place the cursor over links and images on the Patient EDM pages, tooltips appear to provide additional information. Information is also provided to facilitate the use of screen readers and other assistive technology.
The actions you can perform on the Patient EDM are grouped into five primary functions: Person Search, Matching Review, History, Create System Record, and Reports. The main menu on all Patient EDM pages provides hyperlinks to each of these functions, as shown in Figure 3. The first page to appear for each function, except the Create System Record function, is a search page. The names of these headings can be modified for your application.
Person Search – The Person Search function allows you to perform a search for a patient profile or set of patient profiles in Sun Master Patient Index. From the associated pages, you can compare two patient profiles, compare records in one patient profile, view all information for one patient profile, update a patient profile, view a transaction history of a patient profile, view a patient’s potential duplicates, or merge patient profiles or system records.
Matching Review – The Matching Review function allows you to perform a search for potential duplicate profiles or for any profiles that were updated by an assumed match. From the associated pages, you can compare, merge, or resolve potential duplicate profiles, and you can view and reverse assumed match transactions.
History – The History function allows you to perform a search for transaction histories or audit log entries. From the Transaction History pages, you can compare information about a patient before and after a transaction occurred, select patient profiles to unmerge, and view a merge history for a patient profile. From associated Transaction History pages, you can unmerge patient profiles. The audit log pages allow you to view information about transactions in which data about a patient was accessed through the Patient EDM.
Create System Record – The Create System Record function allows you to create new patient profiles by creating a system record. When you save the information in the system record, Sun Master Patient Index automatically generates the SBR using the survivor calculator.
Reports – The Reports function allows you to display and print reports about certain transactions performed from both the Patient EDM and from messages sent in from external systems. For information on configuring reports, see Understanding Sun Master Index Configuration Options (Repository). For information about running reports from a command line, see Maintaining Sun Master Indexes.
When you perform a search for patient information using the Person Search, History, or Matching Review functions, information appears in three different pages. The Search page displays the fields you can use as search criteria, the Search Result page displays a list of search result profiles, and the detail pages display the patient profiles you select from the results list. Once you perform a search, you can navigate back through these pages using the hyperlinks provided in a secondary menu below the main menu, as shown in Figure 4. The Matching Review page for potential duplicate searches includes an additional results page called the Associated Records page.
The behavior of the commands on the secondary menu for Person Search, Matching Review, and History is described in Table 2.
Table 2 Secondary Menu Navigational Tools
Menu Option |
Description |
---|---|
Returns to the original search page with the search criteria filled in. |
|
Returns to the search results list. |
|
Detail Page Name |
This is the name of the current detail page. Clicking this menu option does not perform any action unless you perform a merge from the Comparison page. In this case the Comparison option becomes active and returns to the Comparison page. |
This option becomes available when you select Transaction History or Potential Duplicate from the View/Edit page. It returns to the View/Edit page. |
The detail pages display an EUID tree view of the patient profile on the left and the detailed information for the selected tree-view object on the right. If you are viewing a comparison of patient profiles, the tree views appear in the outer sections of the page, with the detailed information in the center. Figure 5 illustrates the View/Edit page and shows the tree view on the left with the person object of the SBR selected. The detailed information displayed on the right is associated with the selected patient profile. When you select a different object from the tree view, the detailed information in the right portion of the page changes accordingly.
Before you exit the Patient EDM, make sure you have saved any changes. To exit the Patient EDM, click Logout in the upper right corner of the page. The Login page reappears.
Before you can view or update patient information, you need to perform a search for the patient. There are several different search capabilities within the Patient EDM. You can perform lookups for specific patient profiles using unique identifiers such as the EUID or local ID and you can perform broader searches using standard demographic information and parsed address components as criteria.
By default, the Person Search tab includes four different search pages: Simple Person Lookup, Advanced Person Lookup (Alpha), Advanced Person Lookup (Phonetic), and Comparison Lookup. The design of the search functionality provides flexibility in designing database queries. You can narrow a search for a specific patient or a range of patients using various search fields located on the search pages. You can enter search criteria on the Advanced Person Lookup pages and then view your search results on the Search Result page. When you select a specific patient from the Search Result page, detailed information for that patient appears on the View/Edit page.
The Simple Person Lookup page of the Person Search function allows you to perform lookups using unique identifiers to find a specific patient profile. By default, the unique identifiers you can use as search criteria include the EUID, local ID and system, or social security number (SSN) . When you perform this type of search, the Search Result page is generally bypassed and the View/Edit page appears displaying information about the matching profile. An exception to this is when different patient profiles contain the same or very similar SSNs. Performing a search for one of these profiles brings up the Search Result page with a list of matching profiles.
The Advanced Person Lookup (Alpha) page of the Person Search function allows you to perform searches against the database using a combination of demographic and address fields as criteria. The patient profiles returned by these searches are not assigned a matching probability weight to indicate how closely they match the search criteria. The searches performed on this page are exact match searches, meaning that they only return profiles that exactly match the criteria you specify. The only exceptions are street address fields, which are parsed and standardized before searching for matching profiles. Most fields in this search allow wildcard characters if the exact value is unknown.
The Advanced Person Lookup (Phonetic) page of the Person Search function allows you to perform searches against the database using predefined combinations of demographic and address fields as criteria. The patient profiles returned by these searches are assigned a matching probability weight to indicate how closely they match the search criteria. The searches performed on this page are not exact match searches, allowing for misspellings and for nicknames. They do not support wildcard characters.
The Comparison Lookup page of the Person Search function allows you to perform a search for multiple patient profiles by entering their EUIDs. You can then select two of the resulting records to view on the Comparison page. Use this type of search if you want to compare patient profiles and you know the EUIDs of the patient profiles to compare.
The Search Result page of the Person Search function displays a list of patient profiles found in the database that closely match the search criteria you entered. The results list appears in a table, with the number of profiles returned for the search displayed above the table. This page displays information to help you identify the patient profile, such as the EUID, name, date of birth, address information, and status. This page also displays a list of the search criteria entered for the search that returned the displayed list. For more information about search results and the Search Result page, see Working with Search Results on the Patient EDM.
There are several different methods of searching for patients, depending on the search criteria you enter. The search pages of the Person Search function are organized into different sections that allow you to perform different types of searches based on specific categories of criteria. On the Simple Person Lookup page, you can only perform one type of search at a time, using the fields from only one search section.
The names of the search types are configurable. Searches are described below by their default names and by their default search criteria. See your system administrator if you have questions about how your search pages are configured.
You can perform an EUID Lookup using the field in the Enterprise Unique ID section of the Simple Person Lookup page. Enter the patient’s EUID number to perform an exact match search against the database.
A Social Security Number Lookup is used to perform an exact match search against the database using the patient’s social security number (SSN) for search criteria. This type of search is performed in the SSN section of the Simple Person Lookup page.
The Local ID section of the Simple Person Lookup page consists of two required fields, System and Local ID. To increase search accuracy, you can only select a system listed in the drop-down list and the Local ID field is case-sensitive. The name of this section is configurable and might have been modified for your implementation. See your system administrator for more information.
You can perform an alphanumeric search on the Advanced Person Lookup (Alpha) page, using a combination of demographic and address fields as criteria. Using a combination of required and optional fields, you can form a search as precise or general as you prefer. An alphanumeric search looks for profiles that exactly match the criteria as you entered it, without allowing for misspellings or typographic errors. You can use wildcard characters (a percent sign to indicate multiple unknown characters). This type of search also supports searching on a range of values, such as a range of dates for a date of birth.
The Advanced Person Lookup (Phonetic) function differs from the alphanumeric lookup in that it returns phonetic variations of the entered name or street address, allowing room for misspellings and typographic errors. Name and address criteria for phonetic searches are not sensitive to case or to diacritical marks. You can include any combination of address fields in the search, and you can perform partial searches on the street address by only entering the street name. An address search uses the parsed street address field components and the phonetic version of the street name. By default, you can only search on the following data combinations; however, your system might be configured for different combinations.
First Name and Last Name
Address Line 1 and, optionally, Address Line 2
Last Name, Address Line 1, and, optionally, Address Line 2
Social Security Number
First Name, DOB, and Gender
Last Name and Mother’s Maiden Name
The Patient EDM only searches on the above combinations that have complete data. For example, if Last Name, First Name, DOB, and Gender are entered as criteria, only the first and fifth combinations are carried out. The returned result set would include any records that match on first and last name or that match on first name, date of birth, and gender. If only First Name is entered as search criteria, no records are returned since it does not fulfill any of the combination requirements.
The Comparison Lookup function provides a simple way to search for two or more records to compare in a side-by-side comparison. You can enter up to five EUIDs as search criteria, and all records matching any of the specified EUIDs are returned.
Your system administrator can configure the search pages to allow you to enter a range by which to search for certain fields. For example, you might want to search for profiles with a specific first and last name but with a date of birth that falls within a five-year range. If a field is defined for searching by a user-defined range, the Patient EDM displays a “from” field and a “to” field so you can specify the range (for example, “Date From” and “Date To”). If you only enter a value in the “from” field, the Patient EDM searches for profiles with a value greater than or equal to that value. If you only enter a value in the “to” field, the Patient EDM searches for profiles with a value less than or equal to that value.
Ranges can also be defined as the entered value plus or minus a specific value. For example, a date field can be configured to search for dates that fall within a range five years earlier than the date you enter and five years later than the date you enter. Finally, ranges can be defined as specific upper and lower limits. These limits are used when no value is entered. For example, if you perform a search without the date, the Patient EDM searches between the defined lower and upper limits. If you enter only a ”from’ date, the Patient EDM searches between the date you entered and the defined upper limit. For more information about how your system has been configured for range searching, see your system administrator.
Certain fields might be required for the searches on the Patient EDM. If a field is marked with an asterisk (*), it is required. If multiple fields are marked with daggers (†), at least one of those fields must be populated in order to perform the search. The required fields can vary depending on the type of search you are performing.
The following topics provide step-by-step instructions to help you perform the various types of searches available on the Patient EDM. To move from one field to another on the search pages without using the mouse, press the Tab key. The name of the Local ID section is configurable.
Performing a Social Security Number Lookup on the Patient EDM
Performing an Advanced Alphanumeric Lookup on the Patient EDM
To search for a patient profile using only a patient’s EUID, you need to enter the EUID number in the EUID Search section of the Simple Person Lookup page. This type of search should result in only one matching profile.
On the Person Search page, select Simple Person Lookup from the Search Types drop-down list.
In the Enterprise Unique ID section, enter the patient’s EUID.
Click Search or press Enter to initiate the search.
The View/Edit page appears, displaying detailed information about the patient whose EUID you entered.
To search for a patient profile using only the patient’s social security number, use the SSN section of the Simple Person Lookup page (see Figure 6). While this type of search should result in only one matching profile, there might be multiple resulting profiles.
On the Person Search page, select Simple Person Lookup from the Search Types drop-down list.
The Simple Person Lookup page appears (see Figure 6).
In the SSN section, enter the social security number of the patient you want to find.
Click Search or press Enter to initiate the search.
If there are multiple matching profiles, the Search Result page appears with a list of matching profiles. If there is only one matching profile, the Search Result page is bypassed, and the View/Edit page appears.
To search for a patient profile by their local ID in a specific system, you need to enter search criteria in the Local ID section of the Simple Person Lookup page. This type of search should result in only one matching profile. If the Local ID field contains alphabetic characters, the criterion is case-sensitive.
The name of this section might have been modified for your implementation. See your system administrator for more information.
On the Person Search page, select Simple Person Lookup from the Search Types drop-down list.
The Simple Person Lookup page appears (see Figure 6).
In the System field, enter the name of a system for which the local ID is known.
In the Local ID field, enter the patient's local ID in the given system.
If alphabetic characters are entered in this field, the search is case-sensitive. This field name might have been modified for your implementation.
Click Search or press Enter to initiate the search.
The Search Result page is bypassed, and the View/Edit page appears.
To perform an advanced alphanumeric search for a patient profile, you need to specify identifying information for the patient, such as their first and last names, on the Advanced Person Lookup (Alpha) page. This type of search might result in several matching profiles.
On the Person Search page, select Advanced Person Lookup (Alpha) from the Search Types drop-down list.
In the Demographics and Address sections, enter search criteria for the patient you want to find (for more information, see About Alphanumeric Search Fields on the Patient EDM).
Click Search or press Enter to initiate the search.
The Search Result page appears with a list of matching profiles. If only one matching profile is returned, the View/Edit page appears.
The system administrator can choose whether to display the EUID field or the local ID and system fields on this page. Any values entered into these optional fields take precedence over information entered into other search fields. For example, if an invalid EUID is entered but valid first and last names are entered, no results are returned due to the invalid EUID. The EUID field takes precedence over the local ID and system fields.
The alphanumeric search fields, located in the Demographics and Address sections of the Advanced Person Lookup (Alpha) page, allow you to specify search criteria for the patient you want to find. You should make your search as specific as possible. This type of search allows wildcard characters; use a percent sign (%) to indicate any unknown characters.
Any required fields are marked with an asterisk (*). If at least one field in group of fields is required, the fields in that group are marked with a dagger (†). This type of search supports searching by a range of values. Range searching is supported for any field type that has two fields, one with “From” appended to the name and one with “To” appended to the name (for example, “DOB From” and “DOB To”). If your Patient EDM is set up for range searching, see the system administrator for more information about how it is configured.
These fields are defined by default, but your implementation might be configured differently.
To perform an advanced phonetic search for a patient profile, you need to specify identifying information for the patient, such as their first and last names, on the Advanced Person Lookup (Phonetic) page. This search might return several profiles.
On the Person Search page, select Advanced Person Lookup (Phonetic) from the Search Types drop-down list.
In the Demographics and Address sections, enter search criteria for the patient you want to find in one or more of the allowed combinations (at least one combination must be entered).
By default, the following combinations are allowed:
First Name and Last Name
Address Line 1 and, optionally, Address Line 2
Last Name, Address Line 1, and, optionally, Address Line 2
Social Security Number
First Name, DOB, and Gender
Last Name and Mother’s Maiden Name
For more information about these fields, see About Phonetic Search Fields on the Patient EDM. For more information about phonetic searches, see Advanced Person Lookup (Phonetic).
The system administrator might have modified the phonetic search criteria so it is different from the above list. If you are unsure of the required criteria combinations, see your system administrator.
Click Search to initiate the search.
The Search Result page appears with a list of matching profiles. If only one matching profile is found, the results page is bypassed and the View/Edit page appears.
The system administrator can choose whether to display the EUID field or the local ID and system fields on this page. Any values entered into these optional fields take precedence over information entered into other search fields. For example, if an invalid EUID is entered but valid first and last names are entered, no results are returned due to the invalid EUID. The EUID field takes precedence over the local ID and system fields.
The phonetic search fields, located in the Demographics and Address sections of the Advanced Person Lookup (Phonetic) page, allow you to specify search criteria for the patient you want to find. You should make your search as specific as possible. This type of search does not allow wildcard characters.
The Address section consists of fields that are parsed once the search is initiated. Parsed fields are separated into their various components and then standardized before the search is carried out. Parsed fields might include any of the Address Lines 1 through 4 fields, depending on how parsing is configured.
Table 4 Advanced Phonetic Search Fields
To perform a search by EUID for multiple profiles to compare, you need to specify each EUID on the Comparison Lookup page. You can enter from two to five EUIDs to compare in the search results list, and then select one or two of the resulting profiles to compare information.
On the Person Search page, select Comparison Lookup from the Search Types drop-down list.
Enter at least two, and up to five, EUIDs.
Click Search or press Enter to initiate the search.
The Search Result page appears with a list of matching profiles. To learn how to compare profiles, see Comparing Patient Information.
The following topics describe the Search Result page, how to sort and select the profiles that match the searches you perform, and how to print a search result report. The criteria that you entered for a search appear above the results list table on the result page.
The matching profiles that result from a patient search appear in table format on the Search Result page. The table displays a limited number of fields contained in the SBR of the patient profile.
Perform a search for the patient whose profile you want to access.
If more than one record matches the criteria, the Search Result page appears.
In the results list, view the information presented for each returned profile to determine which profile you want to view.
To work with search results, do any of the following:
To view additional address or telephone information, click the ellipsis (“...”) next to the address or telephone entry in the results list.
A popup window appears, as shown in Figure 11 and Figure 12. If there is no ellipses, there is no additional information to view.
To view the following page of search results, click Next>.
To return to the previous page of results, click <Previous.
To sort the search results, click the column heading of the column by which you want to sort the results.
Clicking a heading once sorts the profiles in ascending order; clicking the heading a second time sorts the profiles in descending order. By default, results are sorted by EUID in ascending order.
To view detailed information for a profile or profiles, perform any of the steps described in Selecting a Profile from the Results List.
To perform a new search, click New Search in the upper portion of the page.
To view and print the results in a report, click Print Report.
From the search results list, you can select one patient profile in order to view detailed information for that profile or you can select two patient profiles to compare the information in both profiles. You can also select one patient profile to compare different components of that profile.
Perform a search for the patient profiles you want to view.
To view detailed information for one patient profile, click the EUID of that profile.
The View/Edit page appears, displaying the person object for that profile.
To compare two patient profiles, select the check boxes to the left of each profile you want to compare, and then click Compare Records.
The Comparison page appears, displaying a side-by-side comparison of the two profiles.
To compare different components of one patient profile, select the check box to the left of the profile you want to view, and then click Compare Records.
The Comparison page appears, displaying a side-by-side comparison of two instances of the same patient profile.
Once a comparison check box is selected in the search results list, it remains checked until you clear it. If you return to the Search Result page from the Comparison page, clear the selected check boxes before making another selection.
You can create a report displaying all results of a search, and then print that report to a designated printer.
Perform a search for the patient profiles you want to view.
In the upper right portion of the Search Result page, click Print Report.
The Search Result Report page appears.
To print the report, click Print, and then select a printer from the Print dialog box.
This reporting capability is provided on all search result pages.
Before you can view patient information, you need to perform a search for the patient using one of the search techniques described under Searching for Patient Profiles. Once you retrieve a search results list, you can view a patient’s detailed information, compare patient profiles, view a merge transaction history for a profile, and view a history of all transactions for a profile.
You can view patient information in any of the following formats, which are described in the following topics.
When you select a profile on the Search Result page, detailed information about the selected patient appears on the View/Edit page. This page is divided into two sections. The left side of the page is a tree view that displays the EUID, the components of the SBR, and the components of each system record. You can select a component from the EUID tree to display detailed information about that component in the right portion of the page. The View/Edit page displays the selected patient’s identification, demographic, alias, and local ID information, and you can select an address, telephone number, auxiliary ID, or system record to view additional information. From the View/Edit page, you can perform several actions, such as viewing a transaction history for the patient, viewing potential duplicate profiles, deactivating the profile, updating patient information, and so on.
A tree view on the left side of the View/Edit page displays an outline of the profile, including the SBR and any associated system records. This is called the EUID tree.
You can expand this tree view to view the different types of information contained in the SBR and in each system record. A plus sign (+) to the left of an item indicates that the item contains additional information. For addresses and telephone numbers, only the address or phone type appears in the tree; and for comments, only the comment code appears. For aliases, each alias name appears in the tree.
The right side of the View/Edit page displays detailed information about the item that is selected in the EUID tree. For example, selecting an address type under the SBR entry in the EUID tree displays the detailed information for that address type in the SBR. Selecting “Person” under a source system record in the EUID tree displays demographic information for that patient as it is stored in that system record. The information contained in a patient’s system record might be different from that stored in the patient’s SBR.
By default, you can view the selected patient’s demographic, alias, address, telephone, auxiliary ID, and local ID information for both the SBR and associated system records. For more information about patient profiles, see Learning about Patient Profiles).
You can compare two different patient profiles by selecting the profiles to compare from a search results list. You can also compare different components of one patient profile. The Comparison page allows you to view the selected profiles or components of one profile in a side-by-side comparison with the differences between the two sides highlighted. Like the View/Edit page, the Comparison page displays an EUID tree for each profile, from which you can select the type of information you want to compare. This design allows you to compare one patient’s SBR with another’s SBR, one patient’s system records with another’s system records, or one patient’s SBR with another’s system records. You can also compare a profile’s SBR with one of its own system records or two system records from one profile. This gives you a complete comparison between patient profiles and between the different records in a patient profile.
Differences between displayed profiles are only highlighted when viewing the same type of information on each side. For example, viewing two SBR addresses highlights the differences, but viewing an SBR address and system object address does not. From the Comparison page, you can merge patient profiles or system records if they are found to represent the same patient.
You can view a history of all transactions performed against patient profiles either by performing a search as described in Searching for Patient Profiles or by performing a Transaction History search on the History page (described in Viewing a Patient's Transaction History). You can trace the events that modified a patient profile from the time the profile was added to the master index application up to the most previous transaction, including merged and deactivated profiles.
The Transaction History page allows you to view a side-by-side comparison of one patient profile before and after a transaction occurred against that profile. Like the Comparison page, the Transaction History page displays an EUID tree for each profile, from which you can select the type of information you want to compare with differences between the two profiles highlighted. For a true comparison, be sure the type of information you are viewing is the same on both sides of the page. You can also compare an SBR against an SBR, an SBR against a system record, or a system record against a system record. From associated Transaction History pages, you can unmerge previously merged profiles.
On the Merge History page, you can display a history of the merges that have affected a specific patient profile. The merge history appears in an EUID tree format on the left side of the page. The top level displays the EUID of the current active profile. The two profiles at the second level show you the EUIDs of the profiles that were merged to form the top-level profile. If there are profiles listed at the third level, they display the EUIDs of the profiles that were merged to form the profile above them. There might be several levels of merges displayed in a patient’s merge history.
The right side of the page displays information about the merge transactions that involved the EUID that is selected in the EUID tree on the left. You can select a specific transaction to view a transaction history comparison for that merge transaction.
The audit log allows you to track and view all instances in which information about the patients in the master index application was accessed through the Patient EDM. If audit logging is enabled, an audit log entry is created each time the Patient EDM accesses database tables that contain patient information. The audit log keeps a record of each time the tables are accessed, along with the database function used to access the tables, the login ID of the user accessing the tables, the date and time the tables were accessed, and the EUIDs of the patient profiles that were accessed. This allows you to closely monitor access to the patient records in the master index database and supports HIPAA privacy regulations. The audit log is enabled and disabled in the Enterprise Data Manager file in the Sun Master Patient Index project.
The View/Edit page displays patient profiles in a series of pages you can select and view. Each page except the Person page displays the same four fields in the upper portion to help you identify the patient. These fields are First Name, Last Name, Date of Birth, and Gender. You can view information contained in both the SBR and any associated system records.
The following topics provide the instructions you need to view information associated with a patient profile.
You can view the demographic information contained in a patient’s SBR or in any of the associated system records for that patient. A patient’s SBR contains the demographic information that is determined to be the most current and accurate information about that patient from all local systems. By default, when the View/Edit page first appears, the Person page of the SBR is visible.
The system records associated with a patient profile contain the demographic information that is stored in the external systems that share information with the master index application. The information in a patient’s system records might not match the information stored in the patient’s SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to view on the View/Edit page.
By default, the demographic fields are displayed when the View/Edit page appears. For information about the demographic fields, see About Demographic Fields on the Patient EDM.
To view demographic data in a system record:
In the EUID tree in the left portion of the page, expand Source Systems.
Expand the system and local ID you want to view.
Under the expanded system and local ID, click Person.
You can return to the Person page for the SBR by clicking Person under SBR in the EUID tree on the left side of the page.
From the View/Edit page, you can do any of the following:
To view additional demographic information about the patient, use the scrollbar on the right side of the page.
To modify patient information in the SBR, see Updating the Single Best Record Directly.
To modify patient information in a system record, follow the appropriate procedure under Maintaining Patient Information or Maintaining System Records on the Patient EDM.
To view a history of transactions for the displayed profile, click Transaction History (for more information, see Viewing a Patient's Transaction History).
To view potential duplicates of the displayed profile, click Potential Duplicate (for more information, see Working with Potential Duplicate Patient Profiles).
To view detailed information for the next patient in the search results list, click Next> in the upper portion of the page.
To view detailed information for the previous patient in the search results list, click <Previous in the upper portion of the page.
The fields located on the Person page of the View/Edit page allow you to view detailed demographic information about a patient.
The fields are configurable, and might have been modified or removed. For more information about fields on your Patient EDM that differ from those listed below, see the system administrator. The field descriptions below describe the fields in the default configuration.
This field … |
displays this information ... |
---|---|
The patient’s social security number. |
|
The type of patient whose profile appears, such as employee, patient, customer, vendor, and so on. |
|
The patient’s last name. |
|
The patient’s first name |
|
The middle name or initial of the patient. |
|
The suffix to the patient’s name, such as III, Sr., or M.D. |
|
The patient’s title, such as Ph.D., Medical Doctor, or Reverend. |
|
The month, day, and year that the patient was born. |
|
An indicator of whether the patient is deceased. |
|
The gender of the patient. |
|
The patient’s marital status, such as married, single, divorced, or widowed. |
|
The racial background of the patient, such as Asian, White, or Hispanic. |
|
The ethnic or cultural background of the patient, such as European, French Canadian, or African American. |
|
The name of the patient’s religion or denomination, such as Agnostic, Catholic, or Buddhist. |
|
The patient’s first language. |
|
The first name of the patient’s spouse. |
|
The first name of the patient’s mother. |
|
The maiden name of the patient’s mother. |
|
The first name of the patient’s father. |
|
The maiden name of the patient. |
|
The city in which the patient was born. |
|
The state in which the patient was born. |
|
The country in which the patient was born. |
|
An indicator that specifies the VIP status of the patient. |
|
An indicator that specifies whether the patient is a war veteran. |
|
The driver’s license number of the patient. |
|
The month, day, and year of the patient’s death. |
|
The ID number of the patient’s death certificate. |
|
The nation to which the patient belongs. |
|
The country of which the patient is a citizen. |
|
The ID number of the patient’s pension account. |
|
The expiration date of the patient’s pension. |
|
The patient’s repatriation number. |
|
The patient’s district of residence (DOR). |
|
The patient’s Lga code. |
|
The military branch in which the patient served or is currently serving. |
|
The military rank achieved by the patient in the specified military branch. |
|
The patient’s current status in the specified military branch (such as active or inactive). |
|
These fields might have been customized or removed to suit your company’s specific requirements. For more information about these fields, see the system administrator. |
|
These fields might have been customized or removed to suit your company’s specific requirements. For more information about these fields, see the system administrator. |
|
These fields can only store dates, and might have been customized or removed to suit your company’s specific requirements. For more information about these fields, see the system administrator. |
You can view the address information contained in a patient’s SBR or in any of the associated system records. You can perform several actions against the displayed patient profile, such as viewing a transaction history, modifying patient information, and so on (for more information, see Viewing a Patient’s Demographic Information).
A patient’s SBR contains the address information that is determined to be the most current and accurate information about that patient from all local systems. The system records associated with a patient profile contain the address information that is stored in the external systems that share information with the master index application. The information in a patient’s system records might not match the information stored in the patient’s SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to view on the View/Edit page.
To view an address in the SBR:
To view an address in a system record:
In the EUID tree in the left portion of the page, expand the system and local ID you want to view.
Under the expanded system and local ID, expand Address.
Under Address, click the address type for the address you want to view.
The Address view appears.
For information about the fields on the Address view, see About Address Fields on the Patient EDM.
The fields located on the Address view of the View/Edit page allow you to view detailed address information for the displayed patient profile. Header fields appear at the top of the page to help you identify the patient whose profile you are viewing.
The Address fields are configurable, and might have been modified or removed. For more information about fields on your Addresses page that differ from those listed below, see the system administrator. The field descriptions below describe fields in the default configuration.
This field … |
displays this information ... |
---|---|
Identifying Fields | |
The patient’s last name. |
|
The patient’s first name |
|
The month, day, and year that the patient was born. |
|
The gender of the patient. |
|
Address Fields | |
The type of address displayed, such as home, work, billing, and so on. |
|
Up to four lines of the patient’s address. |
|
The city in which the patient’s address is located. |
|
The state in which the patient’s address is located. |
|
The zip code of the patient’s address. |
|
The 4-digit extension to the patient’s zip code. |
|
The county in which the address is located. |
|
The country in which the address is located. |
You can view the telephone numbers contained in a patient’s SBR or in any of the associated system records. You can perform several actions against the displayed patient profile, such as viewing a transaction history, modifying patient information, and so on (for more information, see Viewing a Patient’s Demographic Information).
A patient’s SBR contains the telephone information that is determined to be the most current and accurate information about that patient from all local systems. The system records associated with a patient profile contain the telephone information that is stored in the external systems that share information with the master index application. The information in a patient’s system records might not match the information stored in the patient’s SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to view on the View/Edit page.
To view a telephone number in the SBR:
To view a telephone number in a system record:
In the EUID tree in the left portion of the page, expand the system and local ID you want to view.
Under the expanded system and local ID, expand Phone.
Under Phone, click the phone type for the telephone number you want to view.
The Phone view appears.
For information about the fields on this page, see About Telephone Fields on the Patient EDM.
The fields located on the Phone view of the View/Edit page allow you to view detailed telephone information for the displayed patient profile. Header fields appear at the top of the page to help you identify the patient whose profile you are viewing.
The fields on the Phone view are configurable, and might have been modified or removed. For more information about fields on your Phone view that differ from those listed below, see the system administrator. The field descriptions below describe the fields in the default configuration.
This field … |
displays this information ... |
---|---|
Identifying Fields | |
The patient’s last name. |
|
The patient’s first name |
|
The month, day, and year that the patient was born. |
|
The gender of the patient. |
|
Telephone Fields | |
The type of telephone number you are viewing, such as home, work, cellular, and so on. |
|
The telephone number for the specified Phone Type. |
|
The extension to the telephone number, if any. |
You can view the alias names contained in a patient’s SBR or in any of the associated system records. You can perform several actions against the displayed patient profile, such as viewing a transaction history, modifying patient information, and so on (for more information, see Viewing a Patient’s Demographic Information).
A patient’s SBR contains the alias names from all of the associated system records, and any alias names that were added specifically to the SBR. The system records associated with a patient profile contain the alias information that is stored in the external systems that share information with the master index application. The information in a patient’s system records might not match the information stored in the patient’s SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to view on the View/Edit page.
To view an alias in the SBR:
To view an alias in a system record:
In the EUID tree in the left portion of the page, expand the system and local ID you want to view.
Under the expanded system and local ID, expand Alias.
Under Alias, click the alias name you want to view.
The Alias view appears.
For information about the fields on this page, see About Alias Fields on the Patient EDM.
The fields located on the Alias view of the View/Edit page allow you to view a patient’s aliases. These names might include nicknames, middle names, or any other names that were previously used by the patient. Header fields appear at the top of the page to help you identify the patient whose profile you are viewing.
The fields on the Alias view are configurable, and might have been modified or removed. For more information about fields on the Alias view that differ from those listed below, see the system administrator. The field descriptions below describe fields in the default configuration.
This field … |
displays this information ... |
---|---|
Identifying Fields | |
The patient’s last name. |
|
The patient’s first name |
|
The month, day, and year that the patient was born. |
|
The gender of the patient. |
|
Alias Fields | |
The last name of the patient’s alias. |
|
The first name of the patient’s alias. |
|
The middle name of the patient’s alias. |
You can view the auxiliary IDs contained in a patient’s SBR or in any of the associated system records. You can perform several actions against the displayed patient profile, such as viewing a transaction history, modifying patient information, and so on (for more information, see Viewing a Patient’s Demographic Information).
A patient’s SBR contains the auxiliary IDs from all of the associated system records, and any auxiliary IDs that were added specifically to the SBR. The system records associated with a patient profile contain the auxiliary IDs that are stored in the external systems that share information with the master index application. The information in a patient’s system records might not match the information stored in the patient’s SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to view on the View/Edit page.
To view an auxiliary ID in the SBR:
To view an auxiliary ID in a system record:
In the EUID tree in the left portion of the page, expand the system and local ID you want to view.
Under the expanded system and local ID, expand AuxId.
Under AuxId, click the auxiliary ID type you want to view.
The Auxiliary ID view appears.
For information about the fields on this page, see About Auxiliary ID Fields on the Patient EDM.
The fields located on the Auxiliary ID view of the View/Edit page allow you to view a patient’s auxiliary IDs assigned within your organization. Header fields appear at the top of the page to help you identify the patient whose profile you are viewing.
The fields on the Auxiliary ID view are configurable, and might have been modified or removed. For more information about fields on this page that differ from those listed below, see the system administrator. The field descriptions below describe the fields in the default configuration.
This field … |
displays this information ... |
---|---|
Identifying Fields | |
The patient’s last name. |
|
The patient’s first name |
|
The month, day, and year that the patient was born. |
|
The gender of the patient. |
|
Auxiliary ID Fields | |
The type of auxiliary ID displayed. |
|
The identification code assigned to the patient that corresponds with the specified ID type. |
You can view the comments associated with a patient’s SBR or in any of the associated system records. You can perform several actions against the displayed patient profile, such as viewing a transaction history, modifying patient information, and so on (for more information, see Viewing a Patient’s Demographic Information).
A patient’s SBR contains the comments associated with all of the associated system records, and any comments that were added specifically to the SBR. The system records associated with a patient profile contain the comments that are stored in the external systems that share information with the master index application. The information in a patient’s system records might not match the information stored in the patient’s SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to view on the View/Edit page.
To view a comment in the SBR:
To view a comment in a system record:
In the EUID tree in the left portion of the page, expand the system and local ID you want to view.
Under the expanded system and local ID, expand Comment.
Under Comment, click the comment code of the comment you want to view.
The Comment page appears.
For information about the fields on this page, see About Comment Fields on the Patient EDM.
The fields located on the Comments view of the View/Edit page allow you to view any comments associated with a patient profile. Header fields appear at the top of the page to help you identify the patient whose profile you are viewing.
The fields on the Comments view are configurable, and might have been modified or hidden by the system administrator. For more information about fields on this page that differ from those listed below, see the system administrator. The field descriptions below describe the fields in the default configuration.
This field … |
displays this information ... |
---|---|
Identifying Fields | |
The patient’s last name. |
|
The patient’s first name |
|
The month, day, and year that the patient was born. |
|
The gender of the patient. |
|
Comment Fields | |
An identification code for the comment that must be unique to each system record. The code must also be unique to the patient profile in order for all comments to appear in the SBR. |
|
The date and time that the displayed comment was created. |
|
The text of the comment. |
You can compare a patient profile before and after a specific transaction occurred, two different patient profiles, or different components within one profile. The following topics provide the step-by-step instructions you need in order to compare patient information in a master index application.
Using the Comparison function of the Patient EDM, you can compare two patient profiles side-by-side to check for similarities and differences. You can also compare different components of the same patient profile. From the EUID trees, you can select the type of information to view and whether to view SBR or system record information.
Using the History function, you can view historical information for a specific patient, and compare the patient’s profile before and after a specific transaction occurred to determine what information was modified as a result of the transaction. The Transaction History page contains an EUID tree for the before image and one for the after image. From the EUID trees you can specify the type of information to view and whether to view SBR or system record information.
The image on the left side of the Transaction History Comparison page reflects the patient’s information before the transaction occurred. The image on the right reflects the patient’s information after the transaction occurred. If the displayed record has no historical data, then the message There is nothing to show in this area appears in the left side of the page.
Obtain information about the patient, such as the EUID, a system in which the patient was registered, or a specific transaction performed against the patient’s profile.
To access a transaction history, you can perform a search for a patient profile, display the profile on the View/Edit page, and then click Transaction History, or you can perform the steps described here.
On the Patient EDM main menu, click History.
The Transaction History Search page appears.
Select History Search from the Search Types drop-down list.
Do one of the following:
To search for a record by system and local ID, enter the system and local ID in the upper section of the window and then click Lookup EUID.
If an EUID is found, it is populated into the EUID field in the Search Criteria section.
To search by EUID or transactional information, enter the search criteria for the patient you want to view (for more information, see About Transaction History Search Fields on the Patient EDM).
On the Transaction History Search page, click Search.
If more than one transaction matches the search, the Transaction History Result page appears with a list of matching profiles (for more information, see About Transaction History Results Fields on the Patient EDM).
If the Transaction History Result page appears, click the transaction number of the transaction you want to view. (If an asterisk appears next to a transaction, it means the transaction history cannot be accessed.)
The Transaction History Comparison page appears, displaying information in the SBR with any differences between the before and after image highlighted in blue.
Select the type of information you want to view from the EUID trees on both sides of the page (for more information, review the instructions and field descriptions under Viewing Patient Profiles).
If you select different types of information from the two sides, differences are not highlighted (for example, if you view SBR address data on one side and system record address data on the other side; or if you view SBR address data on one side and SBR phone data on the other).
If you are viewing a merge transaction, additional options appear in the upper left portion of the page, allowing you to view different images for the transaction (see Figure 25).
If you are viewing an unmerge transaction, additional options appear in the upper right portion of the page, allowing you to view different images for the transaction (see Figure 26).
The fields located on the Transaction History Search page allow you to specify search criteria for the transactions you want to view. Note that the “Lookup By Local ID” section is customizable and might have been changed for your implementation.
Table 11 Transaction History Search Fields
In this field … |
type or select ... |
---|---|
Lookup By Local ID Section | |
The system in which the local ID is known. |
|
The local ID corresponding to the record you want to find and the system selected in the previous field. This field name might be different for your implementation. |
|
Search Criteria Section | |
The patient’s enterprise-wide unique identifier assigned by the master index application. |
|
The type of transaction that caused the patient’s profile to change. See Table 13 for more information about transaction types. |
|
The beginning date for the search. The query is performed for transactions that fall between the From Date and To Date. |
|
The beginning time for the search using 24-hour notation. The query is performed for transactions that fall between the From Time and To Time on the specified dates. If no time is entered, the default value is 00:01 (12:01 A.M.). |
|
The ending date for the search. |
|
The ending time for the search using 24-hour notation. If no time is entered, the default value is 24:00. |
|
The login ID of the user who performed the transaction for which you are searching. |
The fields located on the Transaction History Result page help you identify a specific patient profile and transaction to view. Additional fields might be added to this page by the system administrator. The LID fields and the last name and first name fields are configurable and might have been changed for your implementation.
Table 12 Transaction History Results Fields
This field … |
displays this information … |
---|---|
The sequential identification code of the transaction that caused the transaction history record. |
|
The enterprise-wide unique identification number of the first patient profile involved in the transaction. |
|
The enterprise-wide unique identification number of the second patient profile involved in the transaction. |
|
The name of the system in which the transaction that created the history record occurred. |
|
The local ID of the first system record involved in the transaction. |
|
The local ID of the second system record involved in the transaction. This is only used for system record merges, unmerges, and transfers. |
|
The type of transaction that changed the patient profile and caused the history record to be written. See Table 13 for a description of each transaction type. |
|
The login ID of the user who performed the transaction. |
|
The date and time the transaction occurred. |
|
The patient's first name. |
|
The patient's last name. |
Each transaction performed by the master index application is assigned a transaction type, indicating the type of action that was performed. Table 13 lists and describes each transaction type.
Table 13 Transaction Type Descriptions
Transaction Type |
Description |
---|---|
This transaction type is assigned when a new patient profile is added to the database, whether it is through a direct add or through reversing an assumed match. |
|
This transaction type is assigned when a deactivated patient profile is reactivated. |
|
This transaction type is assigned when an active patient profile is deactivated. |
|
This transaction type is assigned when two patient profiles are merged. |
|
This transaction type is assigned when two patient profiles are unmerged. |
|
This transaction type is assigned when two system records are merged. |
|
This transaction type is assigned when a system record is transferred from one patient profile to another. |
|
This transaction type is assigned when two system records are unmerged. |
|
This transaction type is assigned when a patient profile is modified in any way other than those described above. This includes such transactions as modifying a patient profile, reversing an assumed match, deactivating or reactivating a system record, and adding or removing a child object (such as an address or telephone number). |
To compare two different patient profiles, you must perform a search for the profiles to compare and then select them from the results list. The Comparison page contains an EUID tree on each side of the page, one for each profile you are comparing.
Perform a search for the patient profiles you want to compare, as described in Searching for Patient Profiles.
If you know the EUIDs of the patient profiles to compare, use the Comparison Lookup to retrieve those profiles.
On the search results list, select the check boxes to the left of the two patient profiles you want to compare.
In the first cell of the results table, click Compare Records.
The Comparison page appears with SBR information displayed with any differences between the two profiles highlighted.
To view and compare different types of information, select the type of information you want to view from the EUID trees on both sides of the page (for more information, review the instructions and field descriptions under Viewing Patient Profiles).
If you select different types of information from the two sides, differences are not highlighted (for example, if you view SBR address data on one side and system record address data on the other side; or if you view SBR address data on one side and SBR phone data on the other).
To merge patient information, do either of the following:
To combine the two patient profiles, see Merging Patient Profiles.
To combine two system records in the displayed patient profiles, see Merging System Records on the Patient EDM.
To compare different components of one patient profile, you must perform a search for that profile and then select it from the results list. The Comparison page contains an EUID tree on each side of the page, both containing the most current version of the profile you are comparing.
Perform a search for the patient profile you want to view, as described in Searching for Patient Profiles.
On the search results list, select the check box to the left of the patient profile you want to compare.
In the first cell of the results table, click Compare Records.
The Comparison page appears with SBR information displayed.
To view and compare different types of information, select the type of information you want to view from the EUID trees on both sides of the page (for more information, review the instructions and field descriptions under Viewing Patient Profiles).
If you select different types of information from the two sides, differences are not highlighted (for example, if you view SBR address data on one side and system record address data on the other side; or if you view SBR address data on one side and SBR phone data on the other). However, if you view two different types of addresses the differences are highlighted.
To merge two system records in the displayed patient profile, see Merging System Records on the Patient EDM.
When a patient profile is displayed on the Transaction History page, you can display a history of all merges performed against the profile, allowing you to trace the origin of certain information contained in the profile. You can view a history for each merge transaction in the merge history tree.
The following topics provide information about viewing merge history information.
The master index application tracks all merges performed against each patient profile in the database. You can view a history of merges that affect a specific patient profile and view each EUID that was merged to form the final merge result profile. The merge history appears in a tree structure in the left portion of the Merge History page, showing each pair of profiles that were merged under the displayed patient profile. In the right portion of the page, transaction details appear for the EUID that is highlighted in the merge history tree.
On the Transaction History Search page, perform a search for the patient whose merge history you want to view (for more information, see Viewing a Patient's Transaction History).
On the Transaction History Result page, click the transaction number to the left of the EUID whose merge history you want to view.
The Transaction History page appears.
In the upper portion of the page, click Merge Tree (if Merge Tree is not visible, the EUID does not have a merge history to view).
The Merge History page appears with the merge tree on the left and transaction summaries in the right.
To view a summary of merge transactions for a merged profile, select the EUID of that profile from the merge history tree.
The transaction summary appears in the right portion of the page.
To view transaction information for two merged profiles, click the profile above the merged pair.
Transaction information appears in the right portion of the page.
When you view a patient’s merge history, you can also view a transaction history of any merged pair in the merge history list. The profiles you display from the merge history list contain the information about the profile before the merge occurred.
Display a merge history tree, as described in Viewing a Merge History Tree on the Patient EDM.
Expand the merge history tree in the left portion of the Merge History page until you see the EUID of the patient profile you want to view, and then select that EUID.
In the transaction list in the right portion of the page, click the transaction ID for the merge transaction you want to view.
The Transaction History page appears, displaying transaction details for the transaction you selected.
Using the Audit Log function, you can view a record of each instance an Patient EDM user accessed information about any patient in the master index database. The audit log includes instances in which a patient profile appeared in a search results list; was viewed or compared; was added, updated, or deactivated; or was merged or unmerged. The audit log can be enabled or disabled by the system administrator.
Obtain information about the instances you want to view, such as the EUID, a time frame for when they occurred, the type of function that caused the audit log entries, the user who performed the functions, and so on.
On the Patient EDM main menu, click History.
The History Search page appears with the Transaction History Search page displayed.
Select Audit Log Search from the Search Types drop-down list.
Do one of the following:
To search for a profile by system and local ID, enter the system and local ID in the upper section of the window and then click Lookup EUID.
If an EUID is found, it is populated into the EUID field in the Search Criteria section.
To search by EUID or transactional information, enter the search criteria for the patient you want to view (for more information, see About Audit Log Search Fields on the Patient EDM).
In the right portion of the page, click Search.
The Audit Log Result page appears with a list of instances in which the data was accessed. For information about the fields displayed on this page, see About Audit Log Search Results Fields on the Patient EDM.
To view additional information about a specific Audit Log entry, click an EUID in the row containing the entry you want to view.
The View/Edit page appears.
To view details for the previous entry in the results list, click <Previous.
To view details for the following entry in the results list, click Next>.
The fields located on the Audit Log Search page allow you to enter search criteria about the audit log entries you want to view.
Table 14 Audit Log Search Fields
In this field … |
type or select ... |
---|---|
Lookup By Local ID Section |
|
The system of the system in which the local ID is known. |
|
The local ID corresponding to the record you want to find and the system selected in the previous field. This field name might be different for your implementation. |
|
Search Criteria Section |
|
The patient’s enterprise-wide unique identifier assigned by the master index application. |
|
The category type for the records whose audit log entries you want to view. |
|
The type of transaction that created the audit log entries you want to view. For more information about transaction types, see Audit Log Functions on the Patient EDM. |
|
The login ID of the user whose transactions you want to view. |
|
The beginning date for the search. The query is performed for audit log entries that fall between the From Date and To Date. |
|
The beginning time for the search using 24-hour notation. The query is performed for audit log entries that fall between the From Time and To Time on the specified dates. If no time is specified, the default value is 00:01 (12:01 A.M.). |
|
The ending date for the search. |
|
The ending time for the search using 24-hour notation. If no time is specified, the default value is 24:00. |
The fields located on the Audit Log Result page display information about the instances in which patient data was accessed, where those instances match the search criteria you entered.
Table 15 Audit Log Results Fields
This field … |
displays this information ... |
---|---|
The unique ID code in the audit log for the audit log entry. |
|
The EUID of the first patient profile whose information was accessed. |
|
The EUID of the second patient profile whose information was accessed in the same transaction (as would occur in the case of a profile comparison or merge). |
|
The category type of the patient represented by the EUID. |
|
The primary transaction type that was used to access information. For more information about transaction types, see Audit Log Functions on the Patient EDM. |
|
Specific information about the actions taken against the profile, such as the Patient EDM page that was accessed or the type of function performed against a profile. |
|
The login ID of the user who accessed the information. |
|
The date and time that the information was accessed. |
The audit log creates an audit entry whenever data is accessed through the Patient EDM. The following table lists and describes each audit log function. Some of these functions refer to the actual viewing of data on an Patient EDM page; others refer to an action taken against that data, such as clicking the merge or unmerge Confirm button or resolving a potential duplicate pair.
Table 16 Audit Log Function Descriptions
Audit Log Function |
Description |
---|---|
A user added a new patient profile to the database from the Create System Record page or by reversing an assumed match. |
|
A user viewed profile summaries on the Associated Records page of a potential duplicate search. |
|
A user viewed two assumed match profiles on the Assumed Match page. |
|
A user viewed the results of a search for assumed matches. |
|
A user permanently resolved two potential duplicate records on the Potential Duplicate Comparison page. |
|
A user viewed two patient profiles on the Comparison page. |
|
A user viewed profile summaries on the Search Results page after performing a search for patient profiles. |
|
A user viewed a patient profile on the View/Edit page. |
|
A user initiated a merge of two patient profiles. This function refers to when the user views the merge result prior to clicking Confirm. |
|
A user finalized an unmerge of two patient profiles. |
|
A user initiated an unmerge of two patient profiles. This function refers to when the user views the unmerge result prior to clicking Confirm. |
|
A user compared the before and after image of a patient profile on the Transaction History Comparison page. |
|
A user viewed the results of a transaction history search on the Transaction History Search Results page. |
|
A user initiated a merge of two system records. This function refers to when the user has selected LID Merge but has not finalized the merge. |
|
A user finalized a merge of two system records. |
|
A user finalized an unmerge of two system records. |
|
A user initiated an unmerge of two system records. This function refers to when the user views the unmerge result record prior to clicking Confirm. |
|
A user viewed the results of a search for potential duplicates. |
|
A user finalized a merge of two patient profiles or two system records. |
|
A user viewed a merge tree. This function appears for each patient profile included in the merge tree. |
|
A user viewed two patient profiles on the Potential Duplicate Comparison page. |
|
A user resolved two potential duplicate records on the Potential Duplicate Comparison page. |
|
A user reversed an assumed match. |
|
A user initiated an unmerge of two system records or two patient profiles. This function refers to when the user views the unmerge result record prior to clicking Confirm. |
|
A user changed the status two patient profiles on the Potential Duplicate Comparison page from Resolved to Unresolved. |
|
A user modified a profile on the View/Edit window. Updates include any changes made to a profile, including activating and reactivating system records, adding or removing child objects, and so on. |
|
A user viewed a merge tree. |
This section provides the step-by-step instructions you need in order to add patientprofiles to the master index database. When you add a patient profile, you are actually creating a system record. The master index application calculates the SBR portion of the patient profile when you commit the system record to the database.
Adding a patient profile includes the following steps:
Steps 1, 2, and 3 must be performed in the order given. Steps 4 through 8 can be performed in any order.
Before you begin to add a new patient to the master index application, you should obtain certain information about the patient. For example, by default you must enter the patient’s first and last names, SSN, date of birth in order to save the patient profile. You should provide as much information as is available for each patient. If necessary, review the descriptions of the fields you encounter while adding a new patient. These descriptions, provided throughout this section, will help you to determine the information you need to specify for each new patient. Once you have the information, continue to Step 2: Specify a System and Local ID.
Each patient profile is associated with at least one system record. Before you add demographic data to a patient profile, you must specify the patient’s local ID in a specific system. This creates the system record component of the patient profile.
On the Patient EDM main menu, select Create System Record.
The Create System Record page appears.
Select the system in which you want to add the new profile.
Enter the local ID for the new profile.
By default the name of this field is Local ID, but it might have been customized for your implementation.
Click Add System Record.
The page changes to display demographic fields.
Continue to Step 3: Specify Demographic Information.
When you add a new patient to the master index application, you need to enter certain information such as the patient’s name, social security number, and certain demographic information.
Complete Step 2: Specify a System and Local ID.
On the Create System Record page, enter the patient’s demographic information (for more information, see About Demographic Fields on the Patient EDM).
Do one of the following:
To specify additional information about the patient, continue to Step 4: Specify Alias Information.
To save the patient profile without specifying additional information, skip to Step 9: Save the Patient Profile.
After you specify the required demographic information for a patient, you can specify any alias names for that patient. Once you add an alias, it appears in the patient profile tree on the left side of the Create System Record page.
Complete Step 3: Specify Demographic Information.
In the EUID tree in the left portion of the Create System Record page, select Alias.
The page changes to display alias fields.
On the Create System Record page, enter the patient’s alias information (for more information, see About Alias Fields on the Patient EDM).
In the lower left portion of the page, click Add Alias.
Repeat steps 3 and 4 for each alias name you want to add.
If you add an alias name in error, highlight the alias in the EUID tree, and then click Remove Alias.
The alias name is removed from the tree.
Do one of the following:
To specify additional information about the patient, continue to Step 5: Specify Address Information.
To save the patient profile without specifying additional information, skip to Step 9: Save the Patient Profile.
When you add a new patient to the master index application, you can specify information about the various addresses associated with a patient, such as their home and business addresses.
Complete Step 4: Specify Alias Information.
In the EUID tree in the left portion of the Create System Record page, select Address.
The page changes to display address fields.
On the Create System Record page, fill in the address fields (for more information, see About Address Fields on the Patient EDM).
In the lower portion of the page, click Add Address.
Repeat steps 3 and 4 for each address you need to add to the patient profile.
If you add an address in error, highlight the address type in the EUID tree, and then click Remove Address.
The address is removed from the EUID tree.
Do one of the following:
To specify additional information about the patient, continue to Step 6: Specify Telephone Information.
To save the patient profile without specifying additional information, skip to Step 9: Save the Patient Profile.
When you add a new patient to the master index application, you can specify information about the various telephone numbers associated with a patient, such as their home, cellular, and business telephone numbers.
Complete Step 5: Specify Address Information.
In the EUID tree in the left portion of the Create System Record page, select Phone.
The page changes to display telephone fields.
On the Create System Record page, fill in the telephone fields (for more information, see About Telephone Fields on the Patient EDM).
In the lower portion of the page, click Add Phone.
Repeat steps 3 and 4 for each telephone number you need to add to the patient profile.
If you add a telephone number in error, highlight the telephone type in the EUID tree, and then click Remove Phone.
The number is removed from the tree.
Do one of the following:
To specify additional information about the patient, continue to Step 7: Specify Auxiliary IDs.
To save the patient profile without specifying additional information, skip to Step 9: Save the Patient Profile.
When you add a new patient to the database, you can specify auxiliary IDs for the patient. These IDs do not necessarily uniquely identify the patient profile, and several profiles might have the same ID.
Complete Step 6: Specify Telephone InformationStep 6: Specify Telephone Information.
In the EUID tree in the left portion of the Create System Record page, select AuxId.
The page changes to display auxiliary ID fields.
On the Create System Record page, fill in information about the auxiliary ID (for more information, see About Auxiliary ID Fields on the Patient EDM).
In the lower portion of the page, click Add AuxId.
Repeat steps 3 and 4 for each auxiliary ID you need to add to the patient profile.
If you add an auxiliary ID in error, highlight the auxiliary ID in the EUID tree, and then click Remove AuxId.
The auxiliary ID is removed from the tree.
Do one of the following:
To specify additional information about the patient, continue to Step 8: Add Comments to the Patient Profile.
To save the patient profile without specifying additional information, skip to Step 9: Save the Patient Profile.
When you add a new patient to the master index application, you can specify miscellaneous information about the patient or patient profile in the form of free-text comments.
Complete Step 7: Specify Auxiliary IDs.
In the EUID tree in the left portion of the Create System Record page, select Comment.
The page changes to display comment fields.
On the Create System Record page, fill in the comment fields (for more information, see About Comment Fields on the Patient EDM).
In the lower portion of the page, click Add Comment.
Repeat steps 3 and 4 for each comment you need to add to the patient profile.
If you add a comment in error, highlight the comment code in the EUID tree, and then click Remove Comment.
The comment is removed from the tree.
Continue to Step 9: Save the Patient Profile.
After you specify all the required information for a patient profile, save the profile to the database or the information you entered will be lost.
Complete Step 1: Obtain Information about the Patient through Step 8: Add Comments to the Patient Profile.
Click Commit.
A confirmation dialog box appears.
The confirmation dialog box informs you whether a new profile was added to the database, a new profile was added and it has potential duplicates, or an existing profile was updated with the information you entered.
On the confirmation dialog box, click OK.
The new patient profile is saved to the database.
To add another patient profile, click New Record, and then repeat the steps beginning with Step 1: Obtain Information about the Patient.
Patient profile maintenance involves a number of tasks you can perform to ensure that your database contains the most current and accurate information. These tasks include editing, adding, and deleting patient information, detecting and fixing profiles that are potential duplicates of each other, merging and unmerging patient profiles or system records, and deactivating patient profiles or system records that are no longer active.
The following topics provide additional information to help you understand data maintenance tasks for Sun Master Patient Index.
When you add a new patient profile to master index application, the new profile is automatically checked for any similarities to profiles that already exist in the database. Matching probability weights between existing profiles and the new profile are then calculated using matching algorithm logic. This weight indicates how closely two profiles match each other. If the matching probability weight for two profiles is above a specific number (defined in the Sun Master Patient Index configuration files), the profiles are considered to be potential duplicates. If the weight between two profiles is high enough, they are assumed to be a match and the existing profile is updated with the new information.
You can merge patient profiles that are found to represent the same patient and you can merge system records between patient profiles. During a system record merge, you can specify which fields from each record to retain in the final, merged system record. After a patient profile merge, all information from all the system records involved in the merge is stored in the surviving profile. You might need to review the final merge result profile to determine which, if any, system records should be deactivated.
The SBR for the surviving profile is determined by the survivor calculator, taking into account all system records involved in the merge. If you merge two profiles that have duplicate child objects (for example, each profile has an Office address) and the union survivor calculator is used, then the most recently modified of the two child objects is stored in the SBR.
When you perform a patient profile merge, you are working with two patient profiles. The non-surviving profile is the profile that is not retained after the merge. The surviving profile is retained after the merge. During a patient profile merge, the system records in the non-surviving profile are transferred to the surviving profile, and the non-surviving profile is given a status of “Merged”. The SBR for the surviving patient profile is recalculated based on the existing system records for that profile along with the newly merged system records. The EUID of the surviving profile is always retained. The information that is discarded during a merge is stored in the transaction table, making it possible to restore the profiles to their original EUIDs if they were merged in error.
You can merge two system records together only if they originated from the same external system. The system records can belong to the same patient profile or each can belong to a different profile. When the merge includes two different patient profiles, the profile from which the system record is merged is called the merge from profile; the patient profile into which the system record is merged is called the merge to profile. If you merge the only active system record in one patient profile into a system record in a different patient profile, the merge from profile is deactivated (since there are no active system records remaining, there is nothing from which to create the SBR). During a system record merge, you can select fields from the non-surviving system record to be retained in the surviving system record.
If you merge two patient profiles or system records in error, you can unmerge the profiles or records, moving the information back into the original patient profiles or system records. Any modifications that were made to the surviving patient profile or system record after the merge are retained after the profiles or records are unmerged. If a system record merge caused the “merge from” patient profile to be deactivated, unmerging the system records reactivates that profile.
If you add a new patient profile and the master index application determines that the patient you are adding already exists in the database, the master index application assumes the profiles are a match and updates the existing patient profile. This is known as an assumed match. An assumed match only occurs when the probability of a match between the new profile and the existing profile is above the match threshold specified by your system administrator.
Potential duplicates are two patient profiles that possibly represent the same patient. If you add a new patient and the master index application determines that the patient you are adding might already exist in the database, the two profiles are listed as potential duplicates of one another. Profiles are listed as potential duplicates if the probability of a match between the two profiles is above the duplicate threshold but below the match threshold. Because patient information is entered from various sources, a patient profile might have several potential duplicates. In this case, it is important to identify the potential duplicates and to determine whether the profiles represent the same patient.
The Matching Review function allows you to locate any profiles that are similar enough that they could represent the same patient. You can compare potential duplicate profiles side-by-side to determine if they do represent the same patient. Once you have determined whether the profiles are duplicates, you can use one of the following methods to correct the potential duplicate listing.
If you conclude that the profiles represent the same patient, you need to determine which EUID to retain and then merge the profiles. For a description of the merge process, see Merging Patient Profiles.
If you conclude that two potential duplicate profiles do not represent the same patient, you can mark the profiles as being resolved. Doing this does not change any information for either profile, but it flags them as not being potential duplicates of one another. There are two methods of resolving potential duplicates.
Resolve – This type of resolution allows the profiles to be listed as potential duplicates again if one of the profiles is updated and, after its potential duplicates are reevaluated, the profiles still have a matching weight above the duplicate threshold.
Resolve Permanently – This type of resolution marks the profiles as not being duplicates, and does not allow the pair to be listed as duplicates after any future updates to either record. This is a permanent resolution.
There are special circumstances for updating patient profiles, such as cases where two users update the same profile at the same time, or when updating the SBR rather than updating a system record.
If you have the same patient profile open for editing as another Patient EDM user, only the user who commits their changes first will be able to save their changes. If you try to commit changes after the first user clicks Commit, an error message appears and you will be unable to commit your changes. In order to update the profile with your changes, you must reload the profile by performing a search for that profile. You can then edit the profile and commit your changes.
Every time a system record is updated, the survivor calculator determines whether the new information should be populated into the SBR. This includes updates from the Patient EDM and from local systems. Typically, when you update information in a patient profile, you update the system record, which kicks off the survivor calculator. However, the Patient EDM also allows you update the SBR directly, overriding the survivor calculator's version of the SBR.
When you update an SBR field, the overwrite check box is automatically selected so you can save the changes to the database. You can also select the overwrite check box to lock a value in an SBR field and prevent it from being updated by any system record changes or by the survivor calculator until the overwrite check box is cleared. When a field is unlocked, the survivor calculator immediately recalculates the best value for that field based on the system records in the profile.
If a field in a child object, such as an Address or Phone object, is locked, then the key field (in this case, Address Type or Phone Type), is automatically locked. When you add a child object (such as a telephone number or address) directly to the SBR, all fields in that object are automatically locked and cannot be overwritten by the survivor calculator. If you unlock all the fields in that object, it is removed from the SBR by the survivor calculator.
Use this capability cautiously, since fields updated in the SBR cannot be overwritten by new information from local systems until the overwrite check box is cleared. You can only update an SBR and select or clear the overwrite check box if you have explicit security permissions to do so.
In order to view or modify the fields that are masked by a profile’s VIP status, you must have VIP access permissions. If you do not have VIP access permissions, you cannot add or update a child object, such as an address or telephone number, that contains fields affected by the VIP mask.
You can maintain information in both the SBR and the system records for a patient profile. The following topics provide step-by-step instructions for maintaining up-to-date and accurate patient information in your database.
If a patient’s demographic information changes, you can update the patient’s information in either the SBR or the affected system record. If you update the system record, then the survivor calculator determines what changes, if any, should be made to the SBR. You must have overwrite permissions to update the SBR directly.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Modify the fields in the right portion of the page (for more information, see About Demographic Fields on the Patient EDM).
If you are working in the SBR, select the overwrite check box to the left of the field for each field you modify.
When you are done modifying information, click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
You can add, modify, and delete addresses in a patient profile. If you make any of these modifications to the system record, the survivor calculator determines what changes, if any, should be made to the SBR. You can only modify information in the SBR if you have overwrite permissions.
If a patient submits additional address information, you might need to add a new address record to the SBR or to the affected system record. You can only add one address of each address type to each SBR or each system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Enter the new address information in the fields in the right portion of the page (for more information, see About Address Fields on the Patient EDM).
In the lower left portion of the page, click Add Address.
Click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If you added the address to the SBR, all fields in the address record are automatically locked, and will not be updated by incoming system messages until they are unlocked.
If a patient submits additional address information, you might need to modify an address record in the SBR or the affected system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Select the address type of the address to modify.
Modify the fields in the right portion of the page (for more information, see About Address Fields on the Patient EDM).
If you are working in the SBR, select the overwrite check box to the left of the field for each field you modify.
When you are done modifying information, click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If an address for a patient is entered incorrectly or the patient no longer uses an existing address, you can delete the obsolete address from the affected system record. Once an address is deleted from a patient profile, the deletion cannot be undone.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
To delete an address from a system record, do the following:
To delete an address from the SBR, deselect the overwrite check boxes for all field in the address.
You can only delete an address from the SBR if it was originally added directly to the SBR.
Click Commit.
The page refreshes, and the SBR is recalculated based on the new information.
You can add, modify, and delete telephone numbers in a patient profile. If you make any of these modifications to the system record, the survivor calculator determines what changes, if any, should be made to the SBR. You can only modify information in the SBR if you have overwrite permissions.
If a patient submits additional telephone information, you might need to add a new telephone record to the SBR or to the affected system record. You can only add one telephone number of each phone type to each SBR or each system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Enter the new telephone information in the fields in the right portion of the page (for more information, see About Telephone Fields on the Patient EDM).
In the lower left portion of the page, click Add Phone.
Click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If you added the telephone number to the SBR, all fields in the telephone record are automatically locked, and will not be updated by incoming system messages until they are unlocked.
If a patient changes telephone numbers, you can update those numbers in the SBR or the affected system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Select the phone type of the telephone number to be modified.
Modify the fields in the right portion of the page (for more information, see About Telephone Fields on the Patient EDM).
If you are working in the SBR, select the overwrite check box to the left of the field for each field you modify.
When you are done modifying information, click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If a telephone number for a patient is entered incorrectly or the patient no longer uses an existing number, you can delete the obsolete number from the affected system record. Once a telephone number is deleted from a patient profile, the deletion cannot be undone.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
To delete a telephone number from a system record, do the following:
To delete a telephone number from the SBR, deselect the overwrite check boxes for all field in the address.
You can only delete a telephone number from the SBR if it was originally added directly to the SBR.
Click Commit.
The page refreshes, and the SBR is recalculated based on the new information.
You can add, modify, and delete alias names in a patient profile. If you make any of these modifications to the system record, the survivor calculator determines what changes, if any, should be made to the SBR. You can only modify information in the SBR if you have overwrite permissions.
If you find that a patient is known by a name other than those recorded in the master index application, you can add the name as an alias to the patient’s profile, either to the SBR or the affected system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Enter the new alias information in the fields in the right portion of the page (for more information, see About Alias Fields on the Patient EDM).
In the lower left portion of the page, click Add Alias.
Click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If you added the alias name to the SBR, all fields in the alias record are automatically locked, and will not be updated by incoming system messages until they are unlocked.
If an alias was entered in error for a patient profile, you can modify the alias in the SBR or the affected system record.
Using one of the search methods described in Searching for Patient ProfilesSearching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Select the alias folder containing the alias information you want to modify.
Modify the fields in the right portion of the page (for more information, see About Alias Fields on the Patient EDM).
If you are working in the SBR, select the overwrite check box to the left of the field for each field you modify.
When you are done modifying information, click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If an existing alias name for a patient is no longer valid or was entered in error, you can delete the obsolete alias from the affected system record. Once an alias is deleted from a patient profile, the deletion cannot be undone.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Select Alias under the appropriate system record in the EUID tree in the left portion of the View/Edit page.
Under the Alias node, select the alias you want to remove.
In the lower left portion of the page, click Remove Alias.
Click Commit.
The page refreshes, and the SBR is recalculated based on the new information.
You can add, modify, and delete auxiliary IDs in a patient profile. If you make any of these modifications to the system record, the survivor calculator determines what changes, if any, should be made to the SBR. You can only modify information in the SBR if you have overwrite permissions.
Once you have saved a patient profile, you can add auxiliary IDs to that profile either in the SBR or the affected system record. You can add multiple IDs of the same type to a patient profile. If you add the ID to a system record, then the survivor calculator determines what changes, if any, should be made to the SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Enter the new auxiliary ID information in the fields in the right portion of the page (for more information, see About Auxiliary ID Fields on the Patient EDM).
In the lower left portion of the page, click Add AuxId.
Click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If you added the auxiliary ID to the SBR, all fields in the auxiliary ID record are automatically locked, and will not be updated by incoming system messages until they are unlocked.
If an auxiliary ID was entered in error for a patient profile, you can modify the ID in the SBR or the affected system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Select the ID type of the auxiliary ID you want to modify.
Modify the fields in the right portion of the page (for more information, see About Auxiliary ID Fields on the Patient EDM).
If you are working in the SBR, select the overwrite check box to the left of the field for each field you modify.
When you are done modifying information, click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If an existing auxiliary ID for a patient is no longer valid or was entered in error, you can delete the obsolete ID from the affected system record. Once an auxiliary ID is deleted from a patient profile, the deletion cannot be undone.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
To delete an auxiliary ID from a system record, do the following:
To delete an auxiliary ID from the SBR, deselect the overwrite check boxes for all field in the address.
You can only delete an auxiliary ID from the SBR if it was originally added directly to the SBR.
Click Commit.
The page refreshes, and the SBR is recalculated based on the new information.
You can add, modify, and delete comments in a patient profile. If you make any of these modifications to the system record, the survivor calculator determines what changes, if any, should be made to the SBR. You can only modify information in the SBR if you have overwrite permissions.
If you need to record additional information about a patient, you can add a comment to the patient’s profile, either in the SBR or a system record. Comments can include any information that you feel is relevant for the patient profile, such as a reason for deactivating a profile, notes about possible duplicate profiles, and so on.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Enter the new comment information in the fields in the right portion of the page (for more information, see About Comment Fields on the Patient EDM).
In the lower left portion of the page, click Add Comment.
Click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
If you added the comment to the SBR, all fields in the comment record are automatically locked, and will not be updated by incoming system messages until they are unlocked.
You can modify existing comments in the SBR and in the system records of a patient profile.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
Do one of the following:
Select the comment code of the comment you want to modify.
Modify the fields in the right portion of the page (for more information, see About Comment Fields on the Patient EDM).
If you are working in the SBR, select the overwrite check box to the left of the field for each field you modify.
When you are done modifying information, click Commit.
The page refreshes, and, if you modified a system record, the SBR is recalculated based on the new information.
Once you have added a comment to a patient profile, you can delete the comment from the affected system record if it is no longer useful or accurate. Once a comment is deleted from a patient profile, the deletion cannot be undone.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
To delete a comment from a system record, do the following:
To delete a comment from the SBR, deselect the overwrite check boxes for all field in the address.
You can only delete a comment from the SBR if it was originally added directly to the SBR.
Click Commit.
The page refreshes, and the SBR is recalculated based on the new information.
Unless a field in an SBR is locked for overwrite, the value for that field is recalculated by the survivor calculator each time the patient profile is updated. If you determine that a value in the SBR is the most accurate data and should not be updated, you can lock the field. If you unlock a locked field, the value of that field is automatically recalculated by the survivor calculator as soon as the unlock action is committed.
To learn how to update a field directly in the SBR, see Locking an SBR Field on the Patient EDM.
To learn how to unlock and SBR field so it can be updated by the survivor calculator, see Unlocking an SBR Field on the Patient EDM.
When you lock a field in an SBR, that field can only be updated through the Patient EDM by a user who has overwrite permissions. Locking a field in the SBR removes the survivor calculator from the update process for that field and any updates made to or by system records will not update the locked fields in the SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile containing the field you want to lock on the View/Edit page.
In the EUID tree, select the component in the SBR containing the field you want to lock.
If necessary, update the value of the field to be locked.
Select the overwrite check box to the left of the field.
Click Commit.
The field is now locked and cannot be edited by updates to system records until the lock is removed.
Once you unlock a field for overwrite in an SBR, the SBR is recalculated by the survivor calculator and the field can be updated by changes made to system records. If you added a child object to an SBR and then unlock all fields in the new object, that object is removed from the SBR by the survivor calculator.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile containing the field you want to unlock on the View/Edit page.
In the EUID tree, select the object in the SBR that contains the field you want to unlock.
Clear the overwrite check box to the left of the field you want to unlock.
Click Commit.
The field is now unlocked and can be edited by updates to system records. The SBR is recalculated by the survivor calculator.
You can add, modify, deactivate, and reactivate system records in a patient profile. If you make any of these modifications, the survivor calculator determines what changes, if any, should be made to the SBR.
For instructions on modifying specific information in a system record, see Maintaining Patient Information, which provides links to topics that describe how to maintain various types of information in a patient profile.
If a patient has local IDs in addition to those already recorded in the master index application, you can add the local IDs to the patient’s profile by adding a system record to the profile. To add a local ID to a patient profile, you need to specify information such as the system that assigned the local ID, certain demographic information, and the local ID itself. When you add a system record to a patient profile, the survivor calculator determines what changes, if any, should be made to the SBR.
You cannot add a new local ID and system pair to a patient profile if that same local ID and system pair already exists in another patient profile.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
In the EUID tree in the left portion of the page, select Source Systems.
FollowStep 2: Specify a System and Local ID throughStep 9: Save the Patient Profile.
When you commit the changes, the page refreshes and the SBR is recalculated based on the new information.
You only need to enter required fields in order to save the new system record. Required fields are indicated by an asterisk (*).
If an existing local ID for a patient becomes obsolete, you can deactivate the system record with that local ID for the patient profile. A patient profile must have at least one active local ID; if you deactivate a patient’s last active system record, the entire profile is deactivated. When you deactivate a system record from a patient profile, the survivor calculator determines what changes, if any, should be made to the SBR.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
In the EUID tree in the left portion of the page, expand Source Systems, and then select the system and local ID of the system record you want to deactivate.
Click Deactivate system-ID, where system is the system name and ID is the local ID number for the system record you want to deactivate.
Click Commit.
The page refreshes and the SBR is recalculated based on the new information.
If a system record was deactivated in error or is no longer inactive, you can easily reactivate the system record.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to modify on the View/Edit page.
In the EUID tree in the left portion of the page, expand Source Systems, and then select the system and local ID of the system record you want to reactivate.
Click Activate system-ID, where system is the system name and ID is the local ID number for the system record you want to reactivate.
Click Commit.
The page refreshes and the SBR is recalculated based on the new information.
You can change the status of a patient profile from active to inactive, or from inactive to active. Deactivating a patient profile deactivates all system records associated with that profile and removes the potential duplicate listings for that profile. Reactivating a profile causes the potential duplicates for the profile to be recalculated.
For instructions on changing the status of a profile, see the following topics:
If a patient profile is no longer active, you cannot delete the patient profile, but you can deactivate that profile. Deactivated profiles cannot be modified, and in some cases, cannot be viewed. If you deactivate a profile in error, you can reactivate it if needed.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to update on the View/Edit page.
In the EUID tree in the left portion of the page, highlight the EUID number of the patient profile.
Click Deactivate EUID=EUID_number, where EUID_number is the EUID of the patient profile to deactivate.
In the upper right section of the page, click Commit.
The profile is deactivated in the database and the EUID appears in fuchsia with a tilde (~) next to it.
If a patient profile is deactivated in error or becomes active again, you can reactivate that profile. Reactivating a profile returns the profile to its status just prior to when it was deactivated.
When you reactivate a patient profile, all system records associated with that profile are changed to active status, regardless of their prior status. Review each system record to verify that its status is correct after the reactivation.
Using one of the search methods described in Searching for Patient Profiles, display the patient profile you want to update on the View/Edit page.
In the EUID tree in the left portion of the page, highlight the EUID number of the patient profile.
Click Activate EUID=EUID_number, where EUID_number is the EUID of the patient profile to deactivate.
In the upper right section of the page, click Commit.
The profile is reactivated in the database, the EUID typeface changes from fuchsia to black, and the tilde (~) is removed.
The Matching Review function of the Patient EDM allows you to view any patient profiles that are marked as potential duplicates of each other by the master index application. You can search for and view potential duplicate profiles on the Patient EDM, and then fix the potential duplication by either merging or resolving the two profiles. You can view potential duplicates that are resolved, but not those that are merged.
Perform any of the following tasks to monitor and fix potential duplicate profiles.
Potential duplicate profiles are determined based on the matching probability weight that indicates how closely two profiles match. You can easily find and compare potential duplicate profiles using the Patient EDM.
Obtain information about the patient whose potential duplicates you want to view, such as a system in which they are registered or the login ID of the user who created the patient profile.
On the Patient EDM, select Matching Review.
The Matching Review Search page appears.
On the Matching Review Search page, enter your search criteria (for more information, see About Matching Review Search Fields on the Patient EDM).
In the upper portion of the page, click Search for Potential Duplicate.
If more than one potential duplicate pair matches the search, the Potential Duplicate Result page appears (for more information, see About Potential Duplicate Results Fields on the Patient EDM).
If only one potential duplicate pair matches the search, the Comparison page appears.
In the Results list, click the ID of the pair of potential duplicate profiles you want to compare.
Do one of the following:
If the profiles you selected have additional potential duplicates, then the Associated Records page appears. Continue to step 7.
If the profiles do not have additional duplicates, the Comparison page appears with the two profiles displayed side-by-side (see Figure 53). Skip to step 8.
On the Associated Records page, click the ID of the pair of profiles you want to compare. The Comparison page appears with any differences between the two profiles highlighted in blue (see Figure 53).
If there is more than one page of results on the Associated Records, click Next to view the next page.
To compare additional SBR information for each profile, do any of the following:
To compare address information, expand the Address row under the right and left SBRs, and then select an address type in each.
To compare telephone information, expand the Phone row under the right and left SBRs, and then select a telephone type in each.
To compare alias information, expand the Alias row under the right and left SBRs, and then select an alias name in each.
To compare auxiliary ID information, expand the AuxId row under the right and left SBRs, and then select an auxiliary ID type in each.
To compare comment information, expand the Comment row under the right and left SBRs, and then select a comment code in each.
To compare information contained in the system records of each profile, do any of the following:
To compare address information, expand the Address row under the right and left system records, and then select an address type in each.
To compare telephone information, expand the Phone row under the right and left system records, and then select a telephone type in each.
To compare alias information, expand the Alias row under the right and left system records, and then select the alias name you want to view in each.
To compare auxiliary ID information, expand the AuxId row under the right and left system records, and then select an auxiliary ID type in each.
To compare comment information, expand the Comment row under the right and left system records, and then select a comment code in each.
If you select different types of data for each side, the differences between the two profiles are no longer highlighted (for example, if you choose SBR address data on one side and system record address data on the other, or if you choose SBR address data on one side and SBR phone data on the other).
To view the next entry in the potential duplicate results list, click Next>.
To view the previous entry in the potential duplicate results list, click <Previous.
To return to the potential duplicates results list, click Result.
The fields located on the Matching Review Search page allow you to specify information about the potential duplicate or assumed match profiles you want to view.
Table 17 Matching Review Search Fields
In this field … |
type or select ... |
---|---|
The enterprise-wide unique identification number of one of the profiles you want to view. |
|
The potential duplicate status of the profiles you want to view. Possible values for this field are Unresolved, Resolved, or Permanently Resolved. |
|
The external system with which the patient profile that caused the potential duplicate flag is associated (such as a registration system). |
|
The local ID associated with the patient profile in the specified system. The name of this field might be different for your implementation. |
|
A beginning create date for the profiles you want to view. The query is performed for transactions that were created between the Create Date From (and Create Time From) and the To Create Date (and To Create Time). |
|
The beginning create time for the profiles you want to view (using 24-hour notation). If no time is entered, the default value is 00:01 (12:01 A.M.). |
|
The ending create date for the profiles you want to view. |
|
The ending create time for the profiles you want to view (using 24-hour notation). If no time is entered, the default value is 24:00. |
The fields located in the potential duplicate results list help you to identify a potential duplicate pair to display on the Comparison page.
Table 18 Potential Duplicate Results Fields
This field … |
displays this information … |
---|---|
The potential duplicate ID of the transaction that caused the potential duplicate pair. |
|
The enterprise-wide unique identification number of the patient profile whose addition to the database created the potential duplicate listing. |
|
The enterprise-wide unique identification number of the profile that was flagged as a potential duplicate with the profile identified by EUID1. |
|
The potential duplicate status of the potential duplicate pair. |
|
The reason that the profiles were listed as potential duplicates. |
|
The matching probability weight between the two profiles in each row. |
|
The system with which the patient profile identified by EUID1 is associated. |
|
The date and time that the transaction that caused the potential duplicate listing occurred. |
When you compare two potential duplicate profiles, you might find that the patient profiles represent the same patient, or that a system record from one profile actually belongs in the other profile. You can perform either a patient profile merge or a system record merge to correct this. When you merge two profiles, the SBR of the surviving profile or profiles is automatically recalculated based on the system records involved in the merge.
For more information about merging profiles, see Combining Patient Information.
Compare two potential duplicate profiles, as described in Finding Potential Duplicate Patient Profiles.
Determine which of the two profiles you want to keep, and then click the EUID Merge arrows pointing toward that profile.
The merge result profile appears, allowing you to view the profile that will be saved after the merge.
Click Confirm to finalize the merge, or Cancel to return to the Comparison page and review the profiles again.
Check the surviving patient profiles to determine whether any system records need to be merged or deactivated.
Compare the system records from two potential duplicate profiles, as described in Finding Potential Duplicate Patient Profiles.
Determine which of the two system records you want to keep.
Highlight both system records to be merged, and then click the LID Merge arrows pointing toward the system record you want to keep.
To retain any fields from the non-surviving system record, select the option button next to each field you want to keep.
To specify which child objects to retain, do the following for each type of child object:
In the upper portion of the page, click Merge.
The merge result record appears, allowing you to view the information that will be saved in the SBR after the merge.
Click Confirm to finalize the merge or click Cancel to return to the Comparison page and review the profiles again.
When you compare two potential duplicate profiles and determine that they do not represent the same patient, you can resolve the two profiles to flag the profiles as not being potential duplicates. There are two types of resolution. Resolve removes a potential duplicate flag, but if one of the resolved profiles is updated the records might be listed as potential duplicates again. Resolve Permanently flags the two profiles as being permanently resolved.
Compare two potential duplicate profiles, as described in Finding Potential Duplicate Patient Profiles.
Do one of the following:
On the confirmation dialog box, click OK.
The status of the potential duplicate entry is changed to Resolved and the profiles are no longer regarded as possible duplicates of one another.
The Matching Review function of the Patient EDM allows you to view any patient profiles that were automatically updated by the master index application as a result of an assumed match. You can reverse the assumed match if necessary.
Perform the following tasks to monitor and maintain assumed match profiles:
You can find patient profiles that were updated by an assumed match using the Matching Review function of the Patient EDM. When you search for assumed matches, you can select a patient profile to view from a results list.
Obtain information about the patient profile you want to view, such as their EUID, a system in which they are registered, or the login ID of the user who added the record that caused the update.
On the Patient EDM, select Matching Review.
The Matching Review Search page appears.
On the Matching Review Search page, enter the search criteria (for more information, see About Matching Review Search Fields on the Patient EDM).
In the upper portion of the page, click Search for Assumed Match.
Do one of the following:
If more than one profile matches the search criteria, the Assumed Match Result page appears (for more information, see Figure 59). Continue to step 6.
If only one profile matches the search criteria, the Assumed Match page appears with a comparison of the two profiles that were combined with the differences between the two profiles highlighted in blue. Skip to step 7.
In the Results list, click the ID of the assumed match profile you want to view.
The Assumed Match page appears with the demographic information of the SBR displayed.
To view additional information about the patient, review the instructions provided under Viewing Patient Profiles.
To view the next entry in the assumed match results list, click Next>.
To view the previous entry in the assumed match results list, click <Previous.
To return to the assumed match results list, click Result.
The fields located in the assumed match results list help you to identify an assumed match transaction to display on the Comparison page.
Table 19 Assumed Match Results Fields
This field … |
displays this information … |
---|---|
The assumed match ID of the transaction that caused the assumed match. |
|
The enterprise-wide unique identification number of the patient profile that was updated by the assumed match. |
|
The matching probability weight between the updated profile and the record that caused the assumed match. |
|
The system with which the record that caused the assumed match is associated. |
|
The local ID in the above system for the record that caused the assumed match. The name of this field might be different for your implementation. |
|
The login ID of the user who added the profile that created the assumed match. |
|
The date and time the transaction that caused the assumed match occurred. |
If you find that an assumed match was made in error, you can reverse the assumed match. This process returns the updated patient profile to its status just prior to the assumed match update, creates a new patient profile for the record that caused the assumed match, and recalculates the SBR for the existing profile.
View the assumed match profile, as described in Finding Assumed Matches on the Patient EDM.
In the upper portion of the page, click Undo Assumed Match.
A confirmation dialog box appears, providing the EUID number of the new profile that will be created as a result of reversing the match.
On the confirmation dialog box, click OK.
The assumed match is undone, the updated profile is returned to its state prior to the assumed match, and a new patient profile is created for the system record that caused the assumed match. Any changes that were made after the assumed match but before reversing the assumed match are retained.
When you determine that two patient profiles represent the same patient, you can merge the profiles to form one profile that contains the patient’s most current information. You can also merge system records within one profile or from one profile to another. The resulting profile is called the Merge Result Record. The SBR for the surviving profile or profiles is automatically recalculated based on the system records involved in the merge.
You can display the patient profiles to merge using the Person Search function or the Matching Review function. This section describes how to merge records using the Person Search function. For information about merging records using the Matching Review function, see Merging Potential Duplicate Patient Profiles.
For instructions on combining patient information, see the following topics:
When you merge patient profiles, all of the system records associated with the non-surviving patient profile are transferred to the surviving patient profile. The non-surviving profile is given a status of merged and is no longer active. The SBR of the surviving profile is recalculated based on the new system records that were added to the profile due to the merge. After merging two profiles, review the system records in the active profile to determine whether any of them should be deactivated.
Perform a search for the patient profiles you want to merge using any of the search procedures described in Searching for Patient Profiles.
Select the check boxes to the left of the two profiles you want to merge in the results list.
In the first cell of the results table, click Compare Records.
The Comparison page appears.
Determine which of the two profiles you want to keep, and then click the EUID Merge arrows pointing toward that profile.
The merge result profile appears, allowing you to view the profile that will be saved after the merge.
Click Confirm to finalize the merge, or Cancel to return to the Comparison page and review the profiles again .
You can merge a system record from one patient profile into a system record from another patient profile or you can merge two system records in one profile, as long as both system records originated from the same system. You can also specify which, if any, information to save from the non-surviving system record. When you merge system records, the non-surviving system record is transferred into the patient profile of the surviving system record, and is given a status of merged. The SBR of the surviving profile is automatically recalculated.
If you do not specify which child objects to retain during a merge, the master index application chooses for you; however, the Patient EDM can be configured such that you must select which child objects to retain for certain object types (see your system administrator for more information about how your Patient EDM is configured). If specifying child objects to retain is optional and you do not manually select the child objects, the default is to retain all child objects profiles of a unique type from both system records. If there are any child objects of the same type, the default is to retain only the child object of the surviving system record. For example, if one system record has an office address and the other has a home address, both addresses are retained; but if both system records have a home address, the address of the surviving system record is retained.
Perform a search for the patient profiles whose system records you want to merge using any of the search procedures described in Searching for Patient Profiles.
Select the check boxes to the left of the two profiles containing the system records you want to merge.
In the first cell of the results table, click Compare Records.
The Comparison page appears with the differences between the two records highlighted in blue.
Highlight the Person object of the system records you want to merge in the EUID trees.
Two LID Merge arrow buttons appear at the top of the page.
Click the LID Merge arrows pointing toward the profile containing the system record you want to retain.
To retain any fields from the non-surviving system record, select the Person objects in the system objects to merge, and then select the option button next to each field you want to keep.
To specify which child objects of the two system objects to retain, do the following for each type of child object:
In the upper portion of the page, click Merge.
The merge result record appears, allowing you to view the information that will be saved in the SBR after the merge.
Click Confirm to finalize the merge or click Cancel to return to the Comparison page and review the profiles again.
After you merge two system records, the surviving system record is updated and the non-surviving system record is transferred to the “merge to” patient profile and marked as merged. The SBRs for both patient profiles involved in the merge are recalculated. If the “merge from” patient profile no longer has any system records, it is deactivated.
If two patient profiles or system records are merged in error, you can unmerge the profiles or system records. The unmerge function is accessed from the Transaction History window.
The following topics provide instructions for unmerging profiles and system records.
If two patient profiles are merged in error, the profiles can easily be separated by unmerging the two profiles. When you unmerge two patient profiles, the information is returned to the original profiles, the system records are returned to their original profiles, and any changes that were made after the merge are retained. Any system records that were added while the profiles were merged are associated with the profile that was active at the time. After you unmerge the profiles, verify that the system records were distributed correctly.
Obtain information about the patient profile that is still active after the merge process, such as the EUID, the system that caused the merge, and so on.
Perform a search for the merge transaction, as described in Viewing a Patient's Transaction History.
You can also access the Transaction History Search Result page by displaying the active profile on the View/Edit page, and then clicking Transaction History.
From the Results list, select the merge transaction you want to unmerge. (This must be the most recent merge transaction for the profile and must have a function of EUID Merge.)
The Transaction History page appears.
The profiles that appear on the Transaction History page display the information contained in the surviving patient profile before and after the merge occurred. Select the option button next to the second EUID in the upper portion of the window to view a before image of the non-surviving profile.
In the upper portion of the page, click Unmerge.
The page changes to display side-by-side images of how the records will appear after they are unmerged.
Do one of the following:
If two system records are merged in error, the records can easily be separated by unmerging the two system records. When system records are unmerged, the system record that became inactive is reactivated and, if the system record was merged from a different patient profile, it is returned to its original profile. The SBR is recalculated for all affected patient profiles. Any changes made to the surviving system record following the merge are retained after the unmerge transaction.
Obtain information about either patient profile involved in the merge, such as the EUID, the system that caused the merge, and so on.
Perform a search for the merge transaction, as described in Viewing a Patient's Transaction History.
You can also access the Transaction History Search Result page by displaying the active profile on the View/Edit page, and then clicking Transaction History.
From the Results list, select the merge transaction you want to unmerge. This must be the most recent merge transaction for the system record, and has a function of System Record Merge.
The Transaction History page appears.
The profiles that appear on the Transaction History page display the information contained in the patient profile into which the system record was merged both before and after the merge occurred.
In the upper portion of the page, click Unmerge.
The page changes to display side-by-side images of how the records will appear after they are unmerged.
Do one of the following:
Sun Master Patient Index provides a set of production, activity, and search result reports that can be generated from the Patient EDM. The production reports provide information about the current state of the data in the master index application, helping you monitor stored data and determine how that data needs to be updated. This information also helps verify that the matching logic and weight thresholds are defined correctly. Activity reports provide statistical information for transactions over specific periods of time. Search result reports allow you to print a list of profiles in a search result set.
The following topics provide additional information to help you understand and work with the default reports.
Production reports provide information about the transactions that are processed through the master index database. These reports provide lists of potential duplicate profiles, merge transactions, unmerge transactions, assumed matches, updates, and deactivated profiles for a specified time period. The information you find in these reports provides valuable information about how data is being processed with the current configuration. In addition to running the production reports daily, you should run them against any data that has been loaded from existing systems into the master index database in batch format.
Production reports can be run for the current day, the previous day, or for a date range you specify. If you run your daily reports in the evening, you should run the current day’s reports. If you run your daily reports in the morning, you should run the previous day’s reports.
Assumed Match Report - This report displays information about any profiles that were automatically updated by incoming data during the specified time period. The information in this report, in combination with data from the potential duplicate report, helps you determine whether the matching threshold for assumed matches is accurate. You should review this report daily to ensure that no assumed matches were made in error.
Deactivated Record Report - This report displays a list of all profiles that were deactivated during the specified time period. Review this report daily to ensure that no profiles were deactivated in error. Sun Master Patient Index applications provide the ability to reactivate any deactivated profile.
Potential Duplicate Report - This report displays information about patient profiles that were marked as potential duplicates of one another during the specified time period. The information provided in this report can help you determine whether the matching threshold and the duplicate threshold are configured accurately. Review this report daily to ensure potential duplicates are managed in a timely manner, and use this report as a work list when processing potential duplicates.
Merge Transaction Report - This report displays a list of all enterprise records that were merged during the specified time period. Review this report daily to ensure that no profiles were merged in error. Sun Master Patient Index applications provide the ability to unmerge any merged profiles.
UnMerge Transaction Report - This report displays a list of all enterprise records that were unmerged during the specified time period.
Update Report - This report displays patient profiles whose information was updated during the specified time period. Review this report daily to verify the updates made in a given day. This report can help explain why a resolved potential duplicate listing was reinstated to the potential duplicate list.
Activity reports should be run weekly, monthly, and yearly to obtain statistical data about the transactions that are processed through the master index database. These reports give the number of each type of transaction performed for the specified week, month, or year. They also provide cumulative information for the week, month, or year to date. The information you find in these reports helps analyze the condition of the data by giving you the number of potential duplicates created, the number of assumed matches, and so on.
Weekly Activity Report - This report displays a summary of transactions that occurred against the database on each day for the specified calendar week (always Sunday through Saturday). The information provided in this summary includes the number of each of the following transactions performed each day.
Add
Update
EUID Deactivate
EUID Merge
EUID Unmerge
LID Merge
LID Unmerge
LID Transfer
Monthly Activity Report - This report displays a summary of transactions that occurred against the database during the specified month. You can run this report for any calendar month. The information provided in this summary includes the number of each of the following transactions that were performed for the month:
Add
EUID Deactivate
EUID Merge
EUID Unmerge
LID Merge
LID Unmerge
Unresolved Potential Duplicates
Resolved Potential Duplicates
Yearly Activity Report - This report displays a summary of transactions that occurred against the database for the specified calendar year. You can run this report for any calendar year. The information provided in this report includes a summary of each transaction listed for the monthly activity report above.
In addition to viewing a search result list on the Patient EDM, you can create and print a search result report. This allows you to view a complete list of all profiles in a result set rather than viewing them one page at a time. You can generate search result reports for general, transaction history, assumed match, potential duplicate, and audit log search results. These reports are accessed from the Search Results page for the search you performed. Search result reports can be viewed online or sent to a printer of your choice. The fields that appear on the reports depend on the fields that appear on the Results page for the type of search you performed. For instructions on running a search result report, see Creating and Printing a Search Result Report.
The report files are configured by the Enterprise Data Manager file (edm.xml) in the master index project. For information and instructions on configuring the reports, see Configuring the EDM Reports and Reports Page (Repository) in Configuring Sun Master Indexes (Repository).
Though the Patient EDM can be configured to hide certain fields from users who do not have the appropriate security permissions, reports generated from the Patient EDM will display the hidden data if those fields are configured to appear on the reports. Be sure to only give access to users who should be able to view this information, or do not include hidden fields in the reports.
Reports are run from the Reports page of the Patient EDM and from various Search Result pages. You must have the appropriate security permissions to run the production, activity, and search reports from the Patient EDM. Production and activity reports require that a time period be specified in the search criteria. Both types of report are run from the Reports page on the Patient EDM.
On the Reports Search page, select the type of report to run from the Report Types list, and then fill in the search criteria (see About Report Search Fields on the Patient EDM).
Click Get Report.
The selected report appears (see Figure 63).
To sort the report by a single column, click that column name.
To change whether the column is sorted by ascending or descending order, click again on the column.
To sort by multiple columns, do the following:
Click Advanced Sorting.
The advanced sorting fields appear.
In the first field, select the name of the primary sorting column and then select Descending or Ascending for the sort order.
Repeat the above step for the second and third sorting columns, if any.
Click Sort.
To print the report, click Print in the upper right portion of the window.
The fields on the Report Search page let you specify a date range for each report. For Potential Duplicate reports, you can also specify the status of the potential duplicates returned by the search. For the Weekly Activity Report, you only need to enter one date; the report will automatically display information for the calendar week containing that date.
Table 20 Report Search Fields
In this field ... |
type or select ... |
---|---|
The start date for the report. The report will retrieve transactions that occurred beginning on this date through the date specified in the To Date field. |
|
The start time for the report, in the format HHmmss. |
|
The end date for the report. |
|
The end time for the report, in the format HHmmss. |
|
For Potential Duplicate and Assumed Match reports only, the number of records to display for the report. This allows you to limit the size of the report. |
|
For Potential Duplicate reports only, the status of the potential duplicate pairs to retrieve. You can specify all statuses by leaving this field blank, or you can select Resolved, Unresolved, or Permanently Resolved. This field is not visible for any other type of report. |