Originally developed by EGI in 1995 to allow the EGI Information Team (then consisting of one person) the ability to view the data stored on EGI’s eligibility files, the application known as SGELIG now provides both mainframe and internet access to the eligibility database for authorized HR/Benefits personnel from all UT System component campuses.
What is available through SGELIG?
How does SGELIG get its eligibility information?
SGELIG acts as clearinghouse of sorts for eligibility data. Subscriber information is sent from the components (and in some cases from the vendors) in electronic dataset transmissions. Those datasets are uploaded to the files SGELIG accesses.
Each component maintains a local eligibility database containing information about their employees and retirees. On a regular basis (at least twice monthly), the component creates a dataset of this information and sends it to EGI. Automated procedures at EGI first audit the data and, if audits are passed, upload the records to the files that SGELIG accesses.
In turn, on a regular basis EGI creates datasets from the EGI eligibility files to send to vendors. The vendors audit the information and upload the records that passed the audits into their systems. Through this process, SGELIG reflects information provided by the components, and the vendors reflect information in SGELIG which is provided by EGI. When a record does not pass an audit at EGI or at the vendor, an error for that record is created and added to an error report.
More about your eligibility system and SGELIG
The information seen in SGELIG comes almost entirely from the components. Exceptions include roll forward and rollback data, changes made by the subscriber during Annual Enrollment via UTTOUCH and automatic terminations. However, for the most part, SGELIG reflects the information sent from the components by regular dataset transmission and the information on that dataset is pulled from the component’s eligibility files and system. Some changes are made online in SGELIG, often with a newly hired employee or a subscriber who needs immediate care and whose eligibility is incorrect. These online changes are effective immediately. However, if the same update is not made in the component’s eligibility system, the next dataset EGI receives from that component will not reflect the changes. This will result in the online change being nullified in deference to the dataset record. To ensure online changes remain in effect, be sure to make the same update in your eligibility system.
Why do some subscribers have many records?
One of the primary goals of the EGI Information Sevrices Team is to provide historical records for each Subscriber. When EGI receives a dataset from a component, part of the automated upload process compares the new record to past records sent for the same person. If the records match closely (same SSN, coverage plans, levels and effective dates, zip code, etc), it is considered a duplicate and the new record overwrites the old record resulting in still just one record. However, if the records do not match, for example, the subscriber has changed medical coverage from Subscriber level to Subscriber and Spouse, the new record is considered a completely different entity. The old record is terminated and retained for historical purposes while the new record becomes the active record.