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.