| Installing Upgrading Designing Configuring Deploying Monitoring Administering Troubleshooting Reference JBI Components | |
| Close Print View | |
| Designing: Sun Master Patient Index Enterprise Records |
|
Creating a Runtime Environment
Designing Business Processes in the Sun Business Process Manager
Working with TCP/IP HL7 Collaborations
Developing Sun Master Indexes (Repository)
Developing Sun Master Patient Indexes
Sun Master Patient Index Overview
About Sun Master Patient Index
Sun Master Patient Index Repository Components
Sun Master Patient Index Runtime Environment Components
Master Index Development Process Overview
The Master Patient Index Framework and the Runtime Environment
Before You Begin Developing a Master Index
Preliminary Data Analysis for a Master Index
Planning a Master Index Project
Master Index Project Initiation Checklist
Custom Plug-ins for Master Index Custom Transaction Processing
Master Index Update Policy Plug-ins
Master Index Field Validation Plug-ins
Master Index Field Masking Plug-ins
Master Index Match Processing Logic Plug-ins
Master Index Custom Plug-in Exception Processing
Custom Plug-Ins for Master Index Custom Components
Master Index Survivor Calculator Plug-ins
Master Index Query Builder Plug-ins
Master Index Block Picker Plug-ins
Master Index Pass Controller Plug-ins
Standardization Engine Plug-ins
Phonetic Encoders Plug-ins for a Master Index
Implementing Master Index Custom Plug-ins
Creating Master Index Custom Plug-ins
Building Master Index Custom Plug-ins
Generating the Master Index Application
To Generate the Application for the First Time
Master Index Database Scripts and Design
Master Index Database Requirements
Master Index Database Structure
Designing the Master Index Database
Creating the Master Index Database
Step 1: Analyze the Master Index Database Requirements
Step 2: Create a Master Index Database and User
Step 3: Define Master Index Database Indexes
Step 4: Define Master Index External Systems
Master Index Database Table Description for sbyn_systems
Step 5: Define Master Index Code Lists
Step 6: Define Master Index User Code Lists
Master Index Database Table Description for sbyn_user_code
Step 7: Create Custom Master Index Database Scripts
Step 8: Create the Master Index Database Structure
Step 9: Specify a Starting EUID for a Master Index
Deleting Master Index Database Tables and Indexes
To Delete Database Tables and Indexes
Defining a Database Connection Pool Through the Application Server
Step 1: Add the Oracle Driver to the Application Server
Step 2: Create the JDBC Connection Pools
Step 3: Create the JDBC Resources
Developing OTDs for Application Adapters
Developing OTDs for Communication Adapters
Developing OTDs for Database Adapters
Developing OTDs for Web Server Adapters
Designing with Application Adapters
Designing with Communication Adapters
Designing with Web Server Adapters
Designing with Sun JCA Adapters
An enterprise record is identified by an EUID assigned by Sun Master Patient Index and includes all components of a record that represents one patient. The structure of the data is defined in the Object Definition file.
Sun Master Patient Index stores two different types of records in each enterprise record: system records and a single best record (SBR). A system record contains a patient’s information as it appears in an incoming message from an external system. An enterprise record’s SBR stores data from a combination of external systems and it represents the most reliable and current information contained in all system records for a patient. An enterprise record consists of one or more system records and one SBR.
The structure of a system record is different from the SBR in that each system record contains a system and local ID pair. The remaining information contained in the system records of an enterprise record is used to determine the best data for the corresponding SBR. If an enterprise record only contains one system record, the SBR is identical to that system record (less the system and local ID information). However, if the enterprise record 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.
The SBR for a patient is created from the most reliable information contained in each system record representing that patient. The information used from each external system to populate the SBR is determined by the survivor calculator, which is configured in the Best Record file. This data is determined to be the most reliable information from all system records in the enterprise record. The survivor calculator can consider factors such as the relative reliability of an external system, how recent the data is, and whether the SBR contains any “locked” field values. You define the rules that select a field value to be persisted in the SBR.
In Sun Master Patient Index, each system record and SBR in an enterprise record typically contain a set of objects that store different types of information about a patient. A record contains one parent object and typically contains several child objects, but it can have no child objects at all. A record can have only one instance of the parent object, but can have multiple instances of each type of child object. For example, in the default configuration, the parent object (Person) contains demographic data. A record can only contain one patient name and social security number (stored in the Person object), but the record could have multiple addresses, telephone numbers, and aliases, which are defined in different child objects (address, phone, and alias objects respectively). A record can have multiple instances of each child object, such as a home and a billing address.
Another key component of an enterprise record is the identification codes used to identify and cross-reference each patient. Each record in the master index is assigned an enterprise-wide unique identification number (EUID) in addition to the local IDs assigned by the individual systems in the network. Each unique 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. 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.