Imagine that you are entering data and you notice after the Consent, Inclusion, and Physical Exam pages that using 1 for "Yes" and 2 for "No" makes the entry process go faster. Everything is fine until you get to the Adverse Events page and enter 2 for "Possibly drug related" without really noticing that on this page 1= "No" and 2="Yes". After hearing from the safety desk, you would presumably want to have a quick "discussion" with the OC developer who set up the screens.
Alternatively, suppose you are asked to write some code that joins the QUESTIONS table with the QUESTION_ ATTRIBUTES table. You'll find this easy to do by joining on QUESTION_ID. However, when you're asked to join the REFERENCE _CODELISTS table with the REFERENCE_CODELIST_VALUES table, you will quickly discover that you need to match REFERENCE_CODELIST_NAME from the REFERENCE_CODELIST_VALUES table with REF_CODELIST_NAME from the REFERENCE_CODELIST to get the join you want.
After a few more experiences like these, you'll begin to see the value of having standard naming conventions and making sure they are enforced. You can be sure that for every time that you encounter a situation like this, someone on the analysis end has also encountered two similar variables with different or cryptic names, such as BIRTHDT and BDATE. And it's a safe bet that they will let you, the OC Developer who set up the questions or defined the views, know about it.
The Global Library, or GLIB, is a feature of Oracle Clinical that helps ...