CDW110 EXAM 2023-2024 ACTUAL EXAM 200 QUESTIONS AND CORRECT DETAILED ANSWERS|AGRADE<\/p>\n\n\n\n
CHAPTER 1-Caboodle Console
The Caboodle Console is a web application housed on the Caboodle server. It includes the following:
Dictionary
Dictionary Editor
Executions
Work Queue
Configuration<\/p>\n\n\n\n
CHAPTER 1-Data Warehouse
In a data warehouse, multiple sources may load data pertaining to a single entity. This means that more than one package may populate a given row in a Caboodle table. As a result, there may be multiple business key values associated with a single entity in a Caboodle table.<\/p>\n\n\n\n
CHAPTER 1-ETL
Extract, Transform, Load<\/p>\n\n\n\n
CHAPTER 1-SSIS Package
The architecture of Caboodle includes a staging database and a reporting database. Data is extracted from source systems (like Clarity), transformed in the staging database, and presented for users in the reporting database. This movement of data is realized via a set of SQL Server Integration Services (SSIS) packages.<\/p>\n\n\n\n
CHAPTER 1-Data Lineage
Generally, data lineage refers to the process of identifying the source of a specific piece of information. In Caboodle, data lineage is defined at the package level.<\/p>\n\n\n\n
CHAPTER 1-Star Schema
The standard schema for a dimensional data model. The name refers to the image of a fact table surrounded by many linked dimension tables, which loosely resembles a star.
The Caboodle data model structure is based on a “star schema” \u2010 where one central fact table will join to many associated lookup or dimension tables. This structure provides the foundation of the Caboodle data model.<\/p>\n\n\n\n
CHAPTER 1-DMC
DATA MODEL COMPONENT
No table in Caboodle “stands alone.” Each is considered part of a Data Model Component, which refers to the collection of metadata tables that support the ETL process and reporting views stored in the FullAccess schema.
Each DMC gets a type. Strict table naming conventions are followed in Caboodle, so that a table’s suffix provides information about its structure and purpose.
These suffixes are:
\u00b7 Dim for dimensions (e.g. PatientDim)
\u00b7 Fact for facts (e.g. EncounterFact)
\u00b7 Bridge for bridges (e.g. DiagnosisBridge)
\u00b7 DataMart for data marts (e.g. HospitalReadmissionDataMart)
\u00b7 AttributeValueDim for EAV tables (e.g. PatientAttributeValueDim)
\u00b7 X for custom tables (e.g. CustomFactX)<\/p>\n\n\n\n
CHAPTER 1-Staging Database
The Caboodle database into which records are loaded by SSIS packages and stored procedures.<\/p>\n\n\n\n
CHAPTER 1-Reporting Database
The architecture of Caboodle includes a staging database and a reporting database. Data is extracted from source systems (like Clarity), transformed in the staging database, and presented for users in the reporting database. This movement of data is realized via a set of SQL Server Integration Services (SSIS)
packages.<\/p>\n\n\n\n
CHAPTER 1-Dbo Schema
STAGING DATABASE
Import tables and Mapping tables live here. This is
primarily used by administrators for moving data into Caboodle.<\/p>\n\n\n\n
REPORTING DATABASE
The dbo schema stores reporting data and acts as the
data source for SlicerDicer. The Caboodle Dictionary reflects the contents of the dbo schema.<\/p>\n\n\n\n
CHAPTER 1-FullAccess Schema
STAGING DATABASE
The FullAccess schema does not exist on the Staging database.<\/p>\n\n\n\n
REPORTING DATABASE
The FullAccess schema houses views that simplify reporting. FullAccess should be your default schema when reporting.<\/p>\n\n\n\n
CHAPTER 1-Identify key characteristics of the dimensional data model
MADE for report writers.
\u00b7 Simpler and more intuitive.
\u00b7 Easily extensible.
\u00b7 More performant..<\/p>\n\n\n\n
CHAPTER 1-Identify the benefits of the dimensional data model?
It centralizes its structure around more flexible fact and dimension tables, and the joins between these are more intuitive.<\/p>\n\n\n\n
CHAPTER 1-Identify documentation resources for reporting out of Caboodle
Caboodle Dictionary
Reporting with Caboodle document
Caboodle ER diagram<\/p>\n\n\n\n
CHAPTER 1-Identify reporting needs that best fit Caboodle
Custom data packages can be written by Caboodle developers to accommodate your organization’s reporting needs.<\/p>\n\n\n\n
CHAPTER 1-How does Epic data flow into Caboodle
Epic data moves between several databases before it gets to Caboodle.<\/p>\n\n\n\n
CHRONICLES flows into CLARITY via ETL. After transformation, the data is stored in a relational database on a separate server. Even though the structure of the Chronicles and Clarity databases differ significantly, the ETL process preserves the relationships mapped in Chronicles.<\/p>\n\n\n\n
CLARITY flows into Caboodle data is extracted
from Clarity, transformed in the staging database, and presented for users in the reporting database. This movement of data is realized via a set of SQL Server Integration Services (SSIS) packages.<\/p>\n\n\n\n
CHAPTER 1-How does Non-Epic data flow into Caboodle
The Caboodle developer designs custom DMCs (Data Model Components) and writes SSIS
packages to bring additional data into the warehouse. This may be additional Epic data from Clarity or non\u2010Epic data from 3rd party sources.<\/p>\n\n\n\n
CHAPTER 2-Which of the following would you expect to be stored in a dimension table?
A. Users
B. ED Visits
C. Diagnosis definitions
A. Users
B. ED Visits<\/p>\n\n\n\n
Users and diagnosis definitions would be in their own dimension tables. ED Visits are considered reportable, measureable events and would be in a fact table.<\/p>\n\n\n\n
CHAPTER 2-Which of the following are possible in Caboodle? For each of the answers you select, use the Caboodle Dictionary to find an example.
A. Joining a Fact table to another Fact table
B. Joining a Fact table to a Dimension table
C. Joining a Dimension table to a Dimension table
D. Joining two different Fact tables to the same Profile Dimension table
(Examples may vary)
a. EncounterFact can join to HospitalAdmissionFact
b. MedicationOrderFact can join to PatientDim
c. PatientDim can join to ProviderDim<\/p>\n\n\n\n
CHAPTER 2-Which of the following can be populated by more than one package? Select ALL that apply.
A. A single table
B. A single row in a table
A & B<\/p>\n\n\n\n
CHAPTER 2-TRUE or FALSE: Caboodle and Clarity can be used interchangeably.
FALSE<\/p>\n\n\n\n
CHAPTER 2-Fact Table
The core table types in a dimensional data model are facts and dimensions. A row in a fact table corresponds to the occurrence of some significant, measurable event, such as the ordering of a medication or the posting of a charge transaction.<\/p>\n\n\n\n
A fact table typically contains lookup columns to several dimension tables. This arrangement somewhat resembles a star and so is referred to as a “star schema<\/p>\n\n\n\n
Fact tables typically join to dimension tables, but may also join to other types of DMCs, such as other fact tables and bridge tables.<\/p>\n\n\n\n
All fact tables have a Count column, which stores 0 for the negative rows, 0 for any row that represents deleted data, and 1 otherwise.<\/p>\n\n\n\n
The names of fact tables end with “Fact.”<\/p>\n\n\n\n
All Fact Tables in Caboodle use a surrogate key as their primary key.<\/p>\n\n\n\n
CHAPTER 2-Dimension Table
The core table types in a dimensional data model are facts and dimensions.<\/p>\n\n\n\n
A row in a dimension table represents a concrete entity which provides context for an event, such as the patient for whom a medication was ordered. A fact table typically contains lookup columns to several dimension tables. This arrangement somewhat resembles a star and so is referred to as a “star schema.”<\/p>\n\n\n\n
Fact tables typically join to dimension tables, but may also join to other types of DMCs, such as other fact
tables and bridge tables. It is possible, but not common, for a dimension table to contain lookup columns to other DMCs.<\/p>\n\n\n\n
All Dimension Tables in Caboodle use a surrogate key as their primary key.<\/p>\n\n\n\n
CHAPTER 2-Surrogate Key
A system\u2010generated identifier in Caboodle. Not inherently meaningful to report consumers.<\/p>\n\n\n\n
All fact and dimension tables in Caboodle use a surrogate key as their primary key. Surrogate key column names match the name of the table. Surrogate key values are created during the ETL process. Each
surrogate key value uniquely identifies one row of the table.<\/p>\n\n\n\n
Surrogate key values are not the same as source identifiers.<\/p>\n\n\n\n
CHAPTER 2-Source Identifier
Unique identifier in the source data. Consists of two columns in Caboodle: IdType and Id. Also known as a business key.<\/p>\n\n\n\n
During the ETL process, a load package must provide an IdType and Id, collectively known as the business key. The IdType is a label for the type of identifier loaded by the package while the Id stores the unique identifier of the entity in the source.<\/p>\n\n\n\n
CHAPTER 2-Foreign Key
FOREIGN KEYS in Caboodle end in Key. They are called LOOKUP Columns. It is a column in a table that joins to another table.<\/p>\n\n\n\n
A FOREIGN KEY is a key used to link two tables together. A FOREIGN KEY is a field (or collection of fields) in one table that refers to the PRIMARY KEY in another table. The table containing the foreign key is called the child table, and the table containing the candidate key is called the referenced or parent table.<\/p>\n\n\n\n
CHAPTER 2-Lookup Column
The columns of a fact table contain relevant metrics and foreign keys, or lookup columns, to link out to entities related to the event.<\/p>\n\n\n\n
Lookup columns in Caboodle never contain null or
unmatched values.<\/p>\n\n\n\n
ForeignKeys in Caboodle end in Key; called lookup
columns. Column in a table that joins to another table. Points to another table.<\/p>\n\n\n\n
CHAPTER 3-TRUE or FALSE: Any change to patient data in Clarity will generate a new row in PatientDim after the next extract.
False. Assuming the data is extracted to Caboodle, only changes to Type 2 data would generate a new row in PatientDim.<\/p>\n\n\n\n
CHAPTER 3-What is a durable key?
Type 2 tables have a durable key column which stores the same value for all rows in that table that
correspond to the same entity. This allows for grouping or summarizing data by the entity.<\/p>\n\n\n\n
CHAPTER 3-Change Type
There are two change types: Type 1 and Type 2.<\/p>\n\n\n\n
Caboodle tables and columns are given a change type, which determines whether or not that table or column tracks historical data in the source.<\/p>\n\n\n\n
How a table tracks data over time.<\/p>\n\n\n\n
Type 1 = Current
Type 2 = Storing data over time<\/p>\n\n\n\n
CHAPTER 3-Consider the following query:
SELECT DurableKey FROM
Which of the following statements are true?
A. This query will only run if is Type 2
B. This query will run regardless of the Change Type of
C. The value in the DurableKey column could repeat in multiple rows of the results
D. There is no table in Caboodle for which this query will run
a. This query will only run if is Type 2<\/p>\n\n\n\n
c. The value in the DurableKey column could repeat in multiple rows of the results<\/p>\n\n\n\n
CHAPTER 3-Type 1 Data
Data that is overwritten in Caboodle each time it changes (so no historical values are preserved). For example, a patient’s birth date is Type 1 Data since it is assumed that this would never change (even if it does, the change is likely a correction rather than a genuine change).<\/p>\n\n\n\n
CHAPTER 3-StartDate Column
The StartDate column contains the starting date for which the Type 2 data in the row became valid in
Caboodle.<\/p>\n\n\n\n
CHAPTER 3-EndDate Column
The EndDate column contains the ending date for the range in which the data in the row was valid. TYPE 2<\/p>\n\n\n\n
CHAPTER 3-Durable Key
A durable key is a system\u2010generated identifier that facilitates grouping the rows in a Type 2 table by the entity they represent. For example, each time an employee changes jobs, a new row is created in
EmployeeDim. Every employee would be assigned a single durable key value which is then populated on each of their rows in EmployeeDim.<\/p>\n\n\n\n
Durable Keys store same value for multiple rows that
refer to the same entity in a table<\/p>\n\n\n\n
CHAPTER 3-Durable Key Lookup
Ends in DurableKey: joins to DurableKey column<\/p>\n\n\n\n
CHAPTER 3-Type 2 Entity
Many tables in Caboodle reference patients, providers, and employees. PatientDim, ProviderDim, and EmployeeDim are Type 2 tables in Caboodle.<\/p>\n\n\n\n
Patients, providers, and employees are examples of Type 2 entities in Caboodle. When a fact table references a patient, it is referencing a Type 2 entity, and it has two ways to do so: by the primary key or by the durable key of PatientDim.<\/p>\n\n\n\n
CHAPTER 1-What are the differences between a normalized and dimensional data model?
In a normalized data model, the focus is on not repeating data, which reduces the size of the
database. In a dimensional data model, the focus is on ease of reporting and uses the star schema, which focuses on a central fact table pertaining to a reportable event and surrounding dimension tables providing context for the event.<\/p>\n\n\n\n
CONTEXT\u2026It gives CONTEXT<\/p>\n\n\n\n
CHAPTER 1-Briefly define the roles of the Caboodle report writer, administrator, and developer.
\u00b7 The Caboodle report writer queries data that already exists in the database. They use their knowledge of the tools and the source database(s) to conduct research into the necessary data points required for a given report.<\/p>\n\n\n\n
\u00b7 The Caboodle administrator uses the Caboodle Console to manage and monitor the ETL process. They troubleshoot ETL errors and handle configuration steps for the database.<\/p>\n\n\n\n
\u00b7 The Caboodle developer designs custom DMCs (Data Model Components) and writes SSIS packages to bring additional data into the warehouse. This may be additional Epic data from Clarity or non\u2010Epic data from 3rd party sources.<\/p>\n\n\n\n
CHAPTER 1-TRUE or FALSE: Naming conventions are enforced in Caboodle.
True. Naming conventions, such as Fact, are enforced in Caboodle.<\/p>\n\n\n\n
CHAPTER 1-What is the relationship between SlicerDicer and Caboodle?
SlicerDicer is Epic’s self-service reporting tool in Hyperspace that dynamically queries Caboodle data.<\/p>\n\n\n\n
CHAPTER 4-Suppose you’re creating a report using EncounterFact and ProviderDim that displays the name of each provider for each encounter. If an encounter’s data loads into EncounterFact, but that provider’s data hasn’t been extracted to ProviderDim, what value would appear in ProviderDim.Name for this encounter?
There would be an inferred row in ProviderDim, therefore ProviderDim.Name would show “*Unknown” for the encounter.<\/p>\n\n\n\n
CHAPTER 4-A foreign key column in Caboodle contains the value \u20103. What could this mean?
There are two possibilities: Either the data that once populated this row in Caboodle has been deleted from the source or this is the row with \u20103 as its primary key, for which all foreign key columns are also \u20103. To know which is true, check the primary key value for the given row: a non\u2010negative value indicates that this row represents deleted data in the source.<\/p>\n\n\n\n
CHAPTER 4-If a foreign key is null in Clarity, what will appear in the corresponding column in Caboodle?
If the foreign key was null in the source, then a \u20101 will appear in Caboodle to represent an unspecified value. If the foreign key’s data lineage was not defined by the source package that loaded data for a particular row, then a \u20102 will appear in Caboodle to represent a value that is not applicable.<\/p>\n\n\n\n
CHAPTER 4-A row in a Caboodle table has a primary key value of \u20102. What value will be stored in non\u2010foreign key columns with a data type of “Date” for this row?
A. \u20102
B. NULL
C. 12\/31\/1840
D. *Not Applicable
b. NULL<\/p>\n\n\n\n
For the row with a primary key of \u20102, foreign key columns will store a value of \u20102, string columns will
store ‘*Not Applicable’, and all other data type columns will store NULL.<\/p>\n\n\n\n
CHAPTER 4-TRUE or FALSE: All inferred rows in Caboodle have a primary key of \u20101.
False
Inferred rows in Caboodle have non\u2010negative primary key values because they represent an entity that Caboodle has inferred the existence of. The foreign key columns for such rows will be set to \u20101 until the Caboodle ETL process updates the data.<\/p>\n\n\n\n
CHAPTER 4-Referential Integrity
Referential integrity is enforced in Caboodle, meaning that lookup columns will never contain null values. Furthermore, every value in a lookup column has a match in the destination table.<\/p>\n\n\n\n
Caboodle enforces referential integrity by:<\/p>\n\n\n\n
CHAPTER 4-Inferred Row
When a foreign key value is loaded into Caboodle, the ETL process uses its Id and IdType to determine the correct surrogate key value to store. If the referenced row does not exist yet, the ETL process creates a new row in the target table and assigns a new surrogate key value as its primary key. Such a row is called an inferred row.<\/p>\n\n\n\n
Inferred rows are created when one table has more up-to-date information than another.
Two common scenarios:
A. Unmatched references in the source
B. Testing or development<\/p>\n\n\n\n
Every table in Caboodle has three “extra” rows.
These rows provide a place for foreign keys to point.<\/p>\n\n\n\n
CHAPTER 4-The -1 Row
AS PART OF REFERENTIAL INTEGRITY<\/p>\n\n\n\n
When a foreign key value is NULL in the source system, the foreign key is said to be UNSPECIFIED.
(Unspecified Foreign Key)<\/p>\n\n\n\n
In this case, the corresponding foreign key in Caboodle is set to \u20101.<\/p>\n\n\n\n
Since many date columns in Caboodle are
foreign keys to the DateDim table, NULL dates from Clarity are often represented with a \u20101 value DateKey
columns in Caboodle.<\/p>\n\n\n\n
CHAPTER 4-The -2 Row
AS PART OF REFERENTIAL INTEGRITY<\/p>\n\n\n\n
When a foreign key is not applicable (N\/A) as defined by the SSIS package, Caboodle sets the value to -2. This is handled by the ETL process.<\/p>\n\n\n\n
CHAPTER 4-The -3 Row
AS PART OF REFERENTIAL INTEGRITY<\/p>\n\n\n\n
If an account was deleted in the source, all foreign key values are set to \u20103.<\/p>\n\n\n\n
When a record is hard\u2010deleted in the source system or no longer passes the filters required for extraction,
Caboodle tracks the deletion in one of two ways.<\/p>\n\n\n\n
\u00b7 For Type 1 DMCs, the existing row is updated with default values representing the deletion. The primary key remains unchanged.<\/p>\n\n\n\n
\u00b7 For Type 2 DMCs, a new row is added that represents the deletion. Existing Type 2 data remains, while Type 1 data is overwritten with the default values. The primary key\ufd3es\ufd3f and durable key will remain unchanged.<\/p>\n\n\n\n
CHAPTER 5-What two columns do all bridge tables have?
Every bridge table has a ComboKey to which other tables join and a Foreign Key used to join to its associated dimension table.<\/p>\n\n\n\n
CHAPTER 5-TRUE of FALSE: AttributeValueDim tables are more granular than their associated fact table.
True
The AttributeValueDim tables can store multiple attribute\u2010value combinations on separate rows
for the same entity, making them more granular than their associated fact table<\/p>\n\n\n\n
CHAPTER 5-Bridge Table
Bridge tables exist to capture many\u2010to\u2010many relationships, such as the one between patients and the diagnoses on their problem list.<\/p>\n\n\n\n
Every bridge table has two columns. They are called ComboKey and Key, where is the name of the table to which a bridge has been formed. The<\/p>\n\n\n\n
CHAPTER 5-Entity\u2010Attribute\u2010Value data structure
The entity-attribute-value (EAV) framework allows you to essentially add data to existing Caboodle tables without changing the structure of those tables.<\/p>\n\n\n\n
Values in an EAV model can be any data type, but every value within a column must be the same data type. The typical way to handle this is to make the column a varchar column and store all of the values as a string.<\/p>\n\n\n\n
CHAPTER 5-What is the difference between a MappingFact table and a Bridge table?
Both Bridge tables and MappingFact tables are used to map many\u2010to\u2010many relationships. However, Bridge tables use a combo key as part of their definition and always link to a single dimension table while MappingFact tables may link to one or more fact or dimension tables.<\/p>\n\n\n\n
CHAPTER 5-AttributeValueDim Table
One form of EAV data in Caboodle is the AttributeValueDim DMCs. These tables contain attribute\u2010value pairs and can be created for different entities. For instance, there is the PatientAttributeValueDim table to go along with PatientDim, or the DepartmentAttributeValueDim table to go along with DepartmentDim.<\/p>\n\n\n\n
AttributeValueDim tables are typically Type 2 tables.<\/p>\n\n\n\n
CHAPTER 5-DataMart Table
In the context of Caboodle, data marts are, broadly, collections of Caboodle data on a topic. Some data marts serve as comprehensive data sources for a particular reporting need, making it easier for business intelligence developers to write reports. For example, the HospitalReadmissionAnalyticsDataMart contains all the data relevant for predicting the likelihood of a future hospital readmission.<\/p>\n\n\n\n
Data marts are very similar to fact tables because they both store data about significant, measurable
events and refer to data in dimension tables.<\/p>\n\n\n\n
Data Mart tables typically have a source of “Caboodle”.<\/p>\n\n\n\n
CHAPTER 5-SetDim Tables
STORES GROUPER INFORMATION
In Chronicles, the VCG master file stores groupers, which are lists of Chronicles records (most commonly), ICD codes, or other concepts used together frequently in Hyperspace. VCG groupers are maintained by application analysts in Hyperspace, but can be useful for writing Caboodle reports as well.<\/p>\n\n\n\n
PRACTICE EXAM-Epic recommends using which schema as the default schema for report writing.
CHOOSE ONLY ONE ANSWER
A. dbo schema on staging database
B. dbo schema on the reporting database
C. Epic schema on either database
D. FullAccess schema on the reporting database
D. FullAccess schema on the reporting database<\/p>\n\n\n\n
The FullAccess schema provides a logical layer for report writers in Caboodle. It contains formatting for Boolean columns and performs some simple joins to make reporting easier.<\/p>\n\n\n\n
PRACTICE EXAM-TRUE or FALSE: If a data point exists in Clarity, but not in Caboodle, your organization can create a custom SSIS package to extract it to Caboodle.
TRUE
Caboodle is customizable, meaning your organization can bring in additional data from Clarity as well as third party sources.<\/p>\n\n\n\n
PRACTICE EXAM-PharmacyDim is a Type 1 dimension table in Caboodle. Each pharmacy in Epic has a unique record in the PHR master file. Which of the following best describes the difference between the PharmacyKey and PharmacyEpicId columns in PharmacyDim?
CHOOSE ONLY ONE ANSWER
A. When no PHR record ID exits, PharmacyKey stores -1 and PharmacyEpicId is null
B. When no PHR record ID exits, PharmacyKey is null and PharmacyEpicId is -1
C. PharmacyKey uniquely identifies a row in PharmacyDim; PharmacyEpicId stores the PHR record ID
D. PharmacyKey stores the PHR record ID; PharmacyEpicId uniquely identifies a row in PharmacyDim
C. PharmacyKey uniquely identifies a row in PharmacyDim; PharmacyEpicId stores the PHR record ID.<\/p>\n\n\n\n
A user doesn’t have access to an RW Report unless both the user and the report share a report group in common.<\/p>\n\n\n\n
PRACTICE EXAM-How can you tell if a column is a foreign key in Caboodle?
CHOOSE ALL THAT APPLY
A. The column is marked as Type 2
B. The ER diagram lists it as a foreign key
C. The column is contained in a fact table
D. The destination table is listed to the right of the column description
B. The ER diagram lists it as a foreign key
D. The destination table is listed to the right of the column description<\/p>\n\n\n\n
Type 1 tables do not track changes, so do not need a DurableKey or IsCurrent column.<\/p>\n\n\n\n
PRACTICE EXAM-Tables in Caboodle are categorized as either Type 1 or Type 2. This best describes which of the following?
CHOOSE ONLY ONE ANSWER
A. Caboodle enforces referential integrity
B. Caboodle can track changes in the source
C. Caboodle uses the dimensional data model
D. Caboodle uses the entity-attribute-value data model
B. Caboodle can track changes in the source.<\/p>\n\n\n\n
All Type 2 tables have special columns to help track these changes; DurableKey, StartDate, EndDate, and IsCurrent.<\/p>\n\n\n\n
PRACTICE EXAM-Consider the following query: Which of the following logical expressions will return all hospital admissions where the admitting provider was the same as the discharging provider?
SELECT EncounterEpicCsn, AdmittingProviderKey, DischargingProviderKey
FROM HospitalAdmissionFact
WHERE and AdmittingProviderKey >0 and DischargingProviderKey >0
CHOOSE ONLY ONE ANSWER
A. AdmittingProviderKey = DischaringProviderKey
B. AdmittingProviderDurableKey = DischargingProviderKey
C. AdmittingProviderDurableKey = DischargingProviderDurableKey D. All of the above are equally valid
C. AdmittingProviderDurableKey = DischargingProviderDurableKey<\/p>\n\n\n\n
When comparing type 2 entities, like providers, it most accurage to compare the durable key values, sincy there may be more than one surrogate key value associated with a single entity.<\/p>\n\n\n\n
PRACTICE EXAM-Table A has a foreign key to Table B. An execution runs, which includes a package that loads data to Table A, but does not contain any packages which will populate Table B. Which of the following tables could have an inferred row added to it as a result of this execution?
CHOOSE ONLY ONE ANSWER
A. Only Table A
B. Only Table B
C. Both Table A and Table B
D. Neither Table A nor Table B
B. Only Table B
Inferred rows are created in the table that is referenced by a foreign key’s value. When data is loaded into table A, it’s foreign key is populated. If Table B does not yet have that foreign key value, and inferred row is created.<\/p>\n\n\n\n
PRACTICE EXAM-If the primary key of a row in a fact table is -1, then
CHOOSE ALL THAT APPLY
A. The foreign keys will store -1
B. The foreign keys will store “Unspecified”
C. The foreign keys will store “Unknown”
D. Columns with a data type of varchar will store “Unspecified”
A. The foreign keys will store -1
D. Columns with a data type of varchar will store “Unspecified”<\/p>\n\n\n\n
The -1 row of every Caboodle table behaves in the same way: it’s foreign keys will store -1 “Unspecified”, and all other data type columns will be NULL.<\/p>\n\n\n\n
PRACTICE EXAM-A ComboKey is used as a foregin key to which of the following types of DMCs?<\/p>\n\n\n\n
CHOOSE ONLY ONE ANSWER
Fact
Dimension
SetDim
DataMart
AttributeValueDim
Bridge
Bridge
Although it is the destination of the join, the combo key column of a bridge table is not the primary key. Rather, multiple rows may have the same combo key value.<\/p>\n\n\n\n
OVERALL-Granularity
The level of detail for one row in the table.<\/p>\n\n\n\n
OVERALL-Primary Key
The Primary Key is the column(s) that can uniquely ID a row in a table.<\/p>\n\n\n\n
OVERALL-Surrogate Key
Surrogate Key is a key where the values don’t exist in the source data. These values are NOT in Clarity. They are generated in the ETL process\u2026They are created when moved.<\/p>\n\n\n\n
OVERALL-NAME COVENTIONS IN CABOODLE
Each DMC gets a type. Strict table naming conventions are followed in Caboodle, so that a table’s suffix provides information about its structure and purpose. These suffixes are:
\u00b7 Dim for dimensions (e.g. PatientDim)
\u00b7 Fact for facts (e.g. EncounterFact)
\u00b7 Bridge for bridges (e.g. DiagnosisBridge)
\u00b7 DataMart for data marts (e.g.HospitalReadmissionDataMart)
\u00b7 AttributeValueDim for EAV tables (e.g. PatientAttributeValueDim)
\u00b7 X for custom tables .e.g. CustomFactX<\/p>\n\n\n\n
OVERALL-ER Diagram
An entity\u2010relationship diagram, or ER diagram, is a visual tool that displays information about how database objects relevant to a particular reporting area join to one another. Caboodle ER diagrams are automatically generated for fact tables and data mart tables in the dictionary.<\/p>\n\n\n\n
DEFINITION-SURROGATE KEY
A surrogate key is any column or set of columns that can be declared as the primary key instead of a “real” or natural key. Sometimes there can be several natural keys that could be declared as the primary key, and these are all called candidate keys. So a surrogate is a candidate key.<\/p>\n\n\n\n
OVERALL-CSN
Contact Serial Number<\/p>\n\n\n\n
OVERALL-Type 1
Type 1 tables and columns in Caboodle do not track historical data. When a Type 1 value is updated in the source, all instances of that value in Caboodle are updated the next time the data gets extracted.<\/p>\n\n\n\n
If a table is Type 1—THEN all of the columns in that table are Type 1.<\/p>\n\n\n\n
OVERALL-Type 2
Caboodle retains historical values by creating multiple rows for each entity, with each row containing the values for a particular time period.<\/p>\n\n\n\n
Typically, Type 2 tables contain a mix of Type 1 and Type 2 columns. A Type 2 table must contain at least one Type 2 column.<\/strong> KNOW THIS!!<\/p>\n\n\n\n Type 2 tables typically have a mix of Type 1 and Type 2 columns. Only changes to Type 2 data in the source will result in a new row being added to a Type 2 table for a given entity. When Type 1 data changes, Caboodle stores only the current value in all existing rows for the entity.<\/p>\n\n\n\n OVERALL-IsCurrent OVERALL-Enforcing Referential Integrity OVERALL-Inferred Row KNOW THIS<\/strong> OVERALL-EAV Let’s define these terms by looking at a particular example: suppose your organization is tracking patient hair color. In this case, an ENTITY is a patient and the ATTRIBUTE is hair color. A VALUE would be a particular patient’s hair color, such as red.<\/p>\n\n\n\n (General Reporting Tips) If a query refers to more than one table, all columns should be prefixed by a descriptor (table name or alias) Chapter 1. (Study Checklist) Caboodle Console Chapter 1. (Study Checklist) Data Warehouse Chapter 1. (Study Checklist) ETL Chapter 1. (Study Checklist) SSIS Package Chapter 1. (Study Checklist) Data Lineage Chapter 1. (Study Checklist) Star Schema Chapter 1. (Study Checklist) DMC Chapter 1. (Study Checklist) Staging Database Chapter 1. (Study Checklist) Reporting Database Chapter 1. (Study Checklist) Dbo Schema REPORTING DATABASE Chapter 1. (Study Checklist) FullAccess Schema REPORTING DATABASE (ETL Terms) Execution (ETL Terms) Extract (ETL Terms)package Chapter 1. (Study Checklist) Identify key characteristics of the dimensional data model. Chapter 1. (Study Checklist) Identify documentation resources for reporting out of Caboodle Chapter 1. (Study Checklist) Identify reporting needs that best fit Caboodle (General Reporting Tips) Add a filter to most queries to exclude Caboodle’s special rows for unspecified, not applicable, and deleted records, which have surrogate keys of -1, -2, and -3 (General Reporting Tips) Caboodle has a numbers table, NumbersDim, that you can use as needed in your reports Chapter 1. (Study Checklist) How does Epic data flow into Caboodle CHRONICLES flows into CLARITY via ETL. After transformation, the data is stored in a relational database on a separate server. Even though the structure of the Chronicles and Clarity databases differ significantly, the ETL process preserves the relationships mapped in Chronicles.<\/p>\n\n\n\n CLARITY flows into Caboodle data is extracted Chapter 1. (Study Checklist) How does Non-Epic data flow into Caboodle CHAPTER 1. (Reviewing the Chapter) What are the differences between a normalized and dimensional data model? In a dimensional data model, the focus is on ease of reporting and uses the star schema, which focuses on a central fact table pertaining to a reportable event and surrounding dimension tables providing context for the event.<\/p>\n\n\n\n CONTEXT\u2026It gives CONTEXT<\/p>\n\n\n\n CHAPTER 1. (Reviewing the Chapter) Briefly define the roles of the Caboodle report writer, administrator, and developer. \u00b7 The Caboodle administrator uses the Caboodle Console to manage and monitor the ETL process. They troubleshoot ETL errors and handle configuration steps for the database.<\/p>\n\n\n\n \u00b7 The Caboodle developer designs custom DMCs (Data Model Components) and writes SSIS packages to bring additional data into the warehouse. This may be additional Epic data from Clarity or non\u2010Epic data from 3rd party sources.<\/p>\n\n\n\n CHAPTER 1. (Reviewing the Chapter) TRUE or FALSE: Naming conventions are enforced in Caboodle. CHAPTER 1. (Reviewing the Chapter) What is the relationship between SlicerDicer and Caboodle? Chapter 1. (After-Class Exercise) Where does Epic data in Caboodle come from? Chapter 1. (After-Class Exercise) True or False: Only Epic can Define SSIS packages to move data from Clarity to Caboodle. Chapter 1. (After-Class Exercise) Caboodle is designed to\u2026 (Choose all that apply): Answer: A, B, C, D<\/p>\n\n\n\n Chapter 1. (After-Class Exercise) True or False: Caboodle is considered a normalized database. Chapter 1. (After-Class Exercise) Name three documentation resources for Caboodle Reporting. Chapter 1. (After-Class Exercise) When writing reports, why is it better to use your organization’s Caboodle console rather than the console used in training? Chapter 1. (After-Class Exercise) Use the Caboodle Dictionary to identify the Caboodle tables and columns that extract data from the following items. If you encounter multiple results, write down 2 of them. Chapter 2. (Study Checklist) Fact Table A fact table typically contains lookup columns to several dimension tables. This arrangement somewhat resembles a star and so is referred to as a “star schema<\/p>\n\n\n\n Fact tables typically join to dimension tables, but may also join to other types of DMCs, such as other fact tables and bridge tables.<\/p>\n\n\n\n All fact tables have a Count column, which stores 0 for the negative rows, 0 for any row that represents deleted data, and 1 otherwise.<\/p>\n\n\n\n The names of fact tables end with “Fact.”<\/p>\n\n\n\n All Fact Tables in Caboodle use a surrogate key as their primary key.<\/p>\n\n\n\n Chapter 2. (Study Checklist) Dimension Table A row in a dimension table represents a concrete entity which provides context for an event, such as the patient for whom a medication was ordered. A fact table typically contains lookup columns to several dimension tables. This arrangement somewhat resembles a star and so is referred to as a “star schema.”<\/p>\n\n\n\n Fact tables typically join to dimension tables, but may also join to other types of DMCs, such as other fact All Dimension Tables in Caboodle use a surrogate key as their primary key.<\/p>\n\n\n\n Chapter 2. (Study Checklist) Surrogate Key All fact and dimension tables in Caboodle use a surrogate key as their primary key. Surrogate key column names match the name of the table. Surrogate key values are created during the ETL process. Each Surrogate key values are not the same as source identifiers.<\/p>\n\n\n\n Chapter 2. (Study Checklist) Source Identifier During the ETL process, a load package must provide an IdType and Id, collectively known as the business key. The IdType is a label for the type of identifier loaded by the package while the Id stores the unique identifier of the entity in the source.<\/p>\n\n\n\n For Epic data, columns end in EpicId or EpicCsn<\/p>\n\n\n\n Chapter 2. (Study Checklist) Foreign Key A FOREIGN KEY is a key used to link two tables together. A FOREIGN KEY is a field (or collection of fields) in one table that refers to the PRIMARY KEY in another table. The table containing the foreign key is called the child table, and the table containing the candidate key is called the referenced or parent table.<\/p>\n\n\n\n Chapter 2. (Study Checklist) Lookup Column Lookup columns in Caboodle never contain null or ForeignKeys in Caboodle end in Key; called lookup Chapter 2. (Study Checklist) Where do you look up the data lineage of a table? Chapter 2. (Study Checklist) Where do you look up the data lineage of a column? Chapter 2. (Study Checklist) How would you identify Epic data in Caboodle? Chapter 2. (Study Checklist) How would you identify non-Epic data in Caboodle? Chapter 2. (Study Checklist) The difference between the terms ‘lookup column’ and ‘foreign key’ CHAPTER 2. (Reviewing the Chapter) Which of the following would you expect to be stored in a dimension table? Users and diagnosis definitions would be in their own dimension tables. CHAPTER 2. (Reviewing the Chapter) Which of the following are possible in Caboodle? For each of the answers you select, use the Caboodle Dictionary to find an example. Chapter 2. (Reviewing the Chapter) Which of the following can be populated by more than one package? Select ALL that apply. Chapter 2. (Reviewing the Chapter) TRUE or FALSE: Caboodle and Clarity can be used interchangeably. Chapter 2. (Reviewing the Chapter) True or False: Fact tables can only be joined to dimension tables. Chapter 2. (In-Class Exercises) What is the primary key of MedicationOrderFact? Chapter 2. (In-Class Exercises) How can lookup columns, or foreign keys, be identified in the Dictionary? Chapter 2. (In-Class Exercises) In Caboodle, can a fact table have a lookup column to another fact table? Chapter 2. (In-Class Exercises) What is the difference between MedicationOrderKey and MedicationOrderEpicId? Chapter 2. (In-Class Exercises) Navigate to MedicationDim. What is the difference between MedicationKey and MedicationEpicId? Chapter 2. (In-Class Exercises) True or False: A maximum of one foreign key can exist between two tables in Caboodle? CHAPTER 3. (Reviewing the Chapter) TRUE or FALSE: Any change to patient data in Clarity will generate a new row in PatientDim after the next extract. CHAPTER 3. (Reviewing the Chapter) What is a durable key? CHAPTER 3. (Reviewing the Chapter) Consider the following query: c. The value in the DurableKey column could repeat in multiple rows of the results<\/p>\n\n\n\n CHAPTER 3. (Study Checklist) Change Type Caboodle tables and columns are given a change type, which determines whether or not that table or column tracks historical data in the source.<\/p>\n\n\n\n How a table tracks data over time.<\/p>\n\n\n\n Type 1 = Current CHAPTER 3. (Study Checklist) Type 1 Data CHAPTER 3. (Study Checklist) Type 2 Data CHAPTER 3. (Study Checklist) StartDate Column CHAPTER 3. (Study Checklist) EndDate Column CHAPTER 3. (Study Checklist) Durable Key Durable Keys store same value for multiple rows that CHAPTER 3. (Study Checklist) Durable Key Lookup CHAPTER 3. (Study Checklist) Type 2 Entity Patients, providers, and employees are examples of Type 2 entities in Caboodle. When a fact table references a patient, it is referencing a Type 2 entity, and it has two ways to do so: by the primary key or by the durable key of PatientDim.<\/p>\n\n\n\n CHAPTER 3. (Study Checklist) identify the change type of a table CHAPTER 3. (Study Checklist) Identify the change type of a column? CHAPTER 3. (Study Checklist) Identify whether a change in the source data will trigger an update to an existing value or create a new row CHAPTER 3. (Study Checklist) Use the durable key lookup column to aggregate data CHAPTER 3. (Study Checklist) Join to current data in a Type 2 table<\/p>\n\n\n\n CHAPTER 3. (Study Checklist) How Caboodle tracks changes in the source data CHAPTER 3. (Study Checklist) How the granularity of a Type 2 table differs from the granularity of a Type 1 table CHAPTER 3. (Study Checklist) The difference between the primary key and the durable key of a table<\/p>\n\n\n\n CHAPTER 3. (Study Checklist) The difference between a surrogate key lookup column and a durable key lookup column<\/p>\n\n\n\n CHAPTER 3. (Study Checklist) The difference between a durable key lookup column and a durable key column<\/p>\n\n\n\n CHAPTER 4. (Reviewing the Chapter) Suppose you’re creating a report using EncounterFact and ProviderDim that displays the name of each provider for each encounter. If an encounter’s data loads into EncounterFact, but that provider’s data hasn’t been extracted to ProviderDim, what value would appear in ProviderDim.Name for this encounter? CHAPTER 4-A foreign key column in Caboodle contains the value \u20103. What could this mean? CHAPTER 4-If a foreign key is null in Clarity, what will appear in the corresponding column in Caboodle? CHAPTER 4-A row in a Caboodle table has a primary key value of \u20102. What value will be stored in non\u2010foreign key columns with a data type of “Date” for this row? For the row with a primary key of \u20102, foreign key columns will store a value of \u20102, string columns will CHAPTER 4-TRUE or FALSE: All inferred rows in Caboodle have a primary key of \u20101. CHAPTER 4-Referential Integrity Caboodle enforces referential integrity by:<\/p>\n\n\n\n CHAPTER 4-Inferred Row Inferred rows are created when one table has more up-to-date information than another. Every table in Caboodle has three “extra” rows. CHAPTER 4-The -1 Row When a foreign key value is NULL in the source system, the foreign key is said to be UNSPECIFIED. In this case, the corresponding foreign key in Caboodle is set to \u20101.<\/p>\n\n\n\n Since many date columns in Caboodle are CHAPTER 4-The -2 Row When a foreign key is not applicable (N\/A) as defined by the SSIS package, Caboodle sets the value to -2. This is handled by the ETL process.<\/p>\n\n\n\n CHAPTER 4-The -3 Row If an account was deleted in the source, all foreign key values are set to \u20103.<\/p>\n\n\n\n When a record is hard\u2010deleted in the source system or no longer passes the filters required for extraction, \u00b7 For Type 1 DMCs, the existing row is updated with default values representing the deletion. The primary key remains unchanged.<\/p>\n\n\n\n \u00b7 For Type 2 DMCs, a new row is added that represents the deletion. Existing Type 2 data remains, while Type 1 data is overwritten with the default values. The primary key\ufd3es\ufd3f and durable key will remain unchanged.<\/p>\n\n\n\n CHAPTER 5-What two columns do all bridge tables have? CHAPTER 5-TRUE or FALSE: AttributeValueDim tables are more granular than their associated fact table. CHAPTER 5-Bridge Table Every bridge table has two columns. They are called ComboKey and Key, where is the name of the table to which a bridge has been formed. The<\/p>\n\n\n\n CHAPTER 5-Entity\u2010Attribute\u2010Value data structure Values in an EAV model can be any data type, but every value within a column must be the same data type. The typical way to handle this is to make the column a varchar column and store all of the values as a string.<\/p>\n\n\n\n CHAPTER 5-What is the difference between a MappingFact table and a Bridge table? CHAPTER 5-AttributeValueDim Table AttributeValueDim tables are typically Type 2 tables.<\/p>\n\n\n\n CHAPTER 5-DataMart Table Data marts are very similar to fact tables because they both store data about significant, measurable Data Mart tables typically have a source of “Caboodle”.<\/p>\n\n\n\n CHAPTER 5-SetDim Tables PRACTICE EXAM-A Epic recommends using which schema as the default schema for report writing. The FullAccess schema provides a logical layer for report writers in Caboodle. It contains formatting for Boolean columns and performs some simple joins to make reporting easier.<\/p>\n\n\n\n PRACTICE EXAM-A TRUE or FALSE: If a data point exists in Clarity, but not in Caboodle, your organization can create a custom SSIS package to extract it to Caboodle. PRACTICE EXAM-A PharmacyDim is a Type 1 dimension table in Caboodle. Each pharmacy in Epic has a unique record in the PHR master file. Which of the following best describes the difference between the PharmacyKey and PharmacyEpicId columns in PharmacyDim? A user doesn’t have access to an RW Report unless both the user and the report share a report group in common.<\/p>\n\n\n\n PRACTICE EXAM-A How can you tell if a column is a foreign key in Caboodle? Type 1 tables do not track changes, so do not need a DurableKey or IsCurrent column.<\/p>\n\n\n\n PRACTICE EXAM-A Table A has a foreign key to Table B. An execution runs, which includes a package that loads data to Table A, but does not contain any packages which will populate Table B. Which of the following tables could have an inferred row added to it as a result of this execution? PRACTICE EXAM-A If the primary key of a row in a fact table is -1, then The -1 row of every Caboodle table behaves in the same way: it’s foreign keys will store -1 “Unspecified”, and all other data type columns will be NULL.<\/p>\n\n\n\n PRACTICE EXAM-A ComboKey is used as a foregin key to which of the following types of DMCs?<\/p>\n\n\n\n CHOOSE ONLY ONE ANSWER OVERALL-Granularity OVERALL-Primary Key OVERALL-Surrogate Key OVERALL-NAME COVENTIONS IN CABOODLE OVERALL-ER Diagram DEFINITION-SURROGATE KEY OVERALL-CSN OVERALL-Type 1 If a table is Type 1—THEN all of the columns in that table are Type 1.<\/p>\n\n\n\n OVERALL-Type 2 Typically, Type 2 tables contain a mix of Type 1 and Type 2 columns. A Type 2 table must contain at least one Type 2 column.<\/strong> KNOW THIS!!<\/p>\n\n\n\n Type 2 tables typically have a mix of Type 1 and Type 2 columns. Only changes to Type 2 data in the source will result in a new row being added to a Type 2 table for a given entity. When Type 1 data changes, Caboodle stores only the current value in all existing rows for the entity.<\/p>\n\n\n\n PRACTICE EXAM-A Which of the following types of coumns exist in all fact and dimension tables in Caboodle? Chaoose ALL answers that apply. All fact and dimension tables have a surrogate key primary key column. Fact tables have a Count column, but dimension tables may not. Only snapshot tables have a DurableKey column.<\/p>\n\n\n\n PRACTICE EXAM-A Some tables in Caboodle take snapshots of source data. This best describes which of the following? Choose only ONE answer. Snapshot tables have special columns to help track these changes: DurableKey, StartDate, EndDate and IsCurrent<\/p>\n\n\n\n OVERALL-IsCurrent PRACTICE EXAM-A Consider the following query: Which of the following logical expressions will return all hospital admissions where the admitting provider was the same as the discharging provider? When comparing snapshot entities, like providers, it is most important to compare the durable key values, since there may be more than one surrogate key value associated with a single entity.<\/p>\n\n\n\n OVERALL-Enforcing Referential Integrity OVERALL-Inferred Row KNOW THIS<\/strong> OVERALL-EAV Let’s define these terms by looking at a particular example: suppose your organization is tracking patient hair color. In this case, an ENTITY is a patient and the ATTRIBUTE is hair color. A VALUE would be a particular patient’s hair color, such as red.<\/p>\n\n\n\n (General Modeling Terms) Business Key (General Modeling Terms) Data Lineage (General Modeling Terms) Durable Keys (General Modeling Terms) Foreign Keys (General Modeling Terms) Caboodle contains rows with -1,-2,-3 as the primary keys, to indicate data that is unspecified, not appllicable, or deleted. (General Modeling Terms) Surrogate key (General Modeling Terms) Snapshot data (Dimensional Modeling Terms) Data model component (DMC) (Dimensional Modeling Terms) Fact (Dimensional Modeling Terms) Dimension (Dimensional Modeling Terms) Bridge (Dimensional Modeling Terms) Data Mart (General Reporting Tips) Starting in August 2019, add the following SQL command to the top of every report:SET TRANSACTION ISOLATION LEVEL SNAPSHOT; (General Reporting Tips) Use the views on the FullAccess schema. Materials to Review Before the CDW110v Exam CDW110 EXAM 2023-2024 ACTUAL EXAM 200 QUESTIONS AND CORRECT DETAILED ANSWERS|AGRADE CHAPTER 1-Caboodle ConsoleThe Caboodle Console is a web application housed on the Caboodle server. It includes the following:DictionaryDictionary EditorExecutionsWork QueueConfiguration CHAPTER 1-Data WarehouseIn a data warehouse, multiple sources may load data pertaining to a single entity. This means that more than one package may […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[],"tags":[],"class_list":["post-111008","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/posts\/111008","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/comments?post=111008"}],"version-history":[{"count":0,"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/posts\/111008\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/media?parent=111008"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/categories?post=111008"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.learnexams.com\/blog\/wp-json\/wp\/v2\/tags?post=111008"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
The IsCurrent column is a flag that stores the value of 1 if the row holds the most current information and 0 otherwise.<\/p>\n\n\n\n
Caboodle uses three mechanisms for enforcing referential integrity:
\u00b7 Every table in Caboodle contains three rows with surrogate keys of \u20101, \u20102, and \u20103. These rows serve as the destination for lookup columns in other tables.
\u00b7 When source data is unavailable to populate a lookup column, Caboodle supplies a default value of \u20101, \u20102, or \u20103. Which value is used depends on the circumstance behind the missing information.
\u00b7 When data loaded in one Caboodle table is more up\u2010to\u2010date than data in another table, the Caboodle ETL process generates an inferred row in the delayed table. This row represents the entity being referenced by the more up\u2010to\u2010date table. Inferred rows act as place holders until the relevant information is loaded into Caboodle.<\/p>\n\n\n\n
When a foreign key value is loaded into Caboodle, the ETL process uses its Id and IdType to determine the correct surrogate key value to store. If the referenced row does not exist yet, the ETL process creates a new row in the target table and assigns a new surrogate key value as its primary key. Such a row is called an inferred row.<\/p>\n\n\n\n
When an inferred row is created, all its string values are set to *Unknown. Additionally, all of the inferred row’s foreign key columns are assigned a value of \u20101 and any remaining data columns are set to NULL.
The inferred row is a placeholder, so a later ETL will update these default values when that information is populated in the source database, regardless of the table’s change type<\/p>\n\n\n\n
Entity Attribute Value
The three major components of the EAV data model are entities, attributes, and values.<\/p>\n\n\n\n
Using descriptors ensures you have unambiguous column references, preventing issues that can occur when two tables contain columns with the same name.<\/p>\n\n\n\n
The Caboodle Console is a web application housed on the Caboodle server. It includes the following:
Dictionary
Dictionary Editor
Executions
Work Queue
Configuration<\/p>\n\n\n\n
In a data warehouse, multiple sources may load data pertaining to a single entity. This means that more than one package may populate a given row in a Caboodle table. As a result, there may be multiple business key values associated with a single entity in a Caboodle table.<\/p>\n\n\n\n
Extract, Transform, Load<\/p>\n\n\n\n
The architecture of Caboodle includes a staging database and a reporting database. Data is extracted from source systems (like Clarity), transformed in the staging database, and presented for users in the reporting database. This movement of data is realized via a set of SQL Server Integration Services (SSIS) packages.<\/p>\n\n\n\n
Generally, data lineage refers to the process of identifying the source of a specific piece of information. In Caboodle, data lineage is defined at the package level.<\/p>\n\n\n\n
The standard schema for a dimensional data model. The name refers to the image of a fact table surrounded by many linked dimension tables, which loosely resembles a star.
The Caboodle data model structure is based on a “star schema” \u2010 where one central fact table will join to many associated lookup or dimension tables. This structure provides the foundation of the Caboodle data model.<\/p>\n\n\n\n
DATA MODEL COMPONENT
No table in Caboodle “stands alone.” Each is considered part of a Data Model Component, which refers to the collection of metadata tables that support the ETL process and reporting views stored in the FullAccess schema.
Each DMC gets a type. Strict table naming conventions are followed in Caboodle, so that a table’s suffix provides information about its structure and purpose.
These suffixes are:
\u00b7 Dim for dimensions (e.g. PatientDim)
\u00b7 Fact for facts (e.g. EncounterFact)
\u00b7 Bridge for bridges (e.g. DiagnosisBridge)
\u00b7 DataMart for data marts (e.g. HospitalReadmissionDataMart)
\u00b7 AttributeValueDim for EAV tables (e.g. PatientAttributeValueDim)
\u00b7 X for custom tables (e.g. CustomFactX)<\/p>\n\n\n\n
The Caboodle database into which records are loaded by SSIS packages and stored procedures.<\/p>\n\n\n\n
The architecture of Caboodle includes a staging database and a reporting database. Data is extracted from source systems (like Clarity), transformed in the staging database, and presented for users in the reporting database. This movement of data is realized via a set of SQL Server Integration Services (SSIS)
packages.<\/p>\n\n\n\n
STAGING DATABASE
Import tables and Mapping tables live here. This is
primarily used by administrators for moving data into Caboodle.<\/p>\n\n\n\n
The dbo schema stores reporting data and acts as the
data source for SlicerDicer. The Caboodle Dictionary reflects the contents of the dbo schema.<\/p>\n\n\n\n
STAGING DATABASE
The FullAccess schema does not exist on the Staging database.<\/p>\n\n\n\n
The FullAccess schema houses views that simplify reporting. FullAccess should be your default schema when reporting.<\/p>\n\n\n\n
An execution is the process that extracts data from a source system using packages, transforms the data in the staging database, and loads it to Caboodle for reporting. You create and run executions in the Caboodle Console.<\/p>\n\n\n\n
Extracts to Caboodle from Clarity can be either backfill or incremental. Backfill extracts load or reload every row in a table from Clarity, whereas incremental extracts load only changed rows. Existing data is available while extracts are in progress.<\/p>\n\n\n\n
A package is a definition of an extract of data from one specific source to a specific import table. For example, a fact might have packages for Epic inpatient data, Epic outpatient data, and several non-Epic data sources. Packages are defined in SSIS .dtsx files.<\/p>\n\n\n\n
MADE for report writers.
\u00b7 Simpler and more intuitive.
\u00b7 Easily extensible.
\u00b7 More performant..<\/p>\n\n\n\n
Caboodle Dictionary
Reporting with Caboodle document
Caboodle ER diagram<\/p>\n\n\n\n
Custom data packages can be written by Caboodle developers to accommodate your organization’s reporting needs.<\/p>\n\n\n\n
Include only rows where the key is greater than 0.<\/p>\n\n\n\n
NumbersDim contains the integers from 1 to 1,000,000, which you can reference to help manipulate strings and complete other processes. If you need more than 1,000,000 rows to accomplish a task, you can refer to NumbersDim multiple times in your query.<\/p>\n\n\n\n
Epic data moves between several databases before it gets to Caboodle.<\/p>\n\n\n\n
from Clarity, transformed in the staging database, and presented for users in the reporting database. This movement of data is realized via a set of SQL Server Integration Services (SSIS) packages.<\/p>\n\n\n\n
The Caboodle developer designs custom DMCs (Data Model Components) and writes SSIS
packages to bring additional data into the warehouse. This may be additional Epic data from Clarity or non\u2010Epic data from 3rd party sources.<\/p>\n\n\n\n
In a normalized data model, the focus is on not repeating data, which reduces the size of the
database.<\/p>\n\n\n\n
\u00b7 The Caboodle report writer queries data that already exists in the database. They use their knowledge of the tools and the source database(s) to conduct research into the necessary data points required for a given report.<\/p>\n\n\n\n
True. Naming conventions, such as Fact, are enforced in Caboodle.<\/p>\n\n\n\n
SlicerDicer is Epic’s self-service reporting tool in Hyperspace that dynamically queries Caboodle data.<\/p>\n\n\n\n
From Clarity, which gets its data from Chronicles<\/p>\n\n\n\n
False.<\/p>\n\n\n\n
A. Store Epic data
B. Store non-Rpic Data
C. Make reporting easy
D. Interoperate with SlicerDicer
E. Store all of the data from Clarity.<\/p>\n\n\n\n
False. Clarity is a normalized database. Caboodle has been denormalized in order to simplify reporting.<\/p>\n\n\n\n
Caboodle Dictionary
Reporting with Caboodle document
Caboodle ER Diagram<\/p>\n\n\n\n
The Console used in training will not reflect your organization’s custom development. For that reason, it is best to use your Caboodle Console rather than Epic’s training tools for writing reports.<\/p>\n\n\n\n
A. CVG 410 (termination date): CoverageDim.CoverageTerminationDate
B. FSD 1230 (whether a flowsheet value reading is abnormal) FlowsheetValueFact.Abnormal
c. HSB 89210 (anesthesia start time): AnesthesiaRecordFact.AnethesiaStartInstant
D. LPL 1164 (present on admisiion diadnoses): DiagnosisEventFact.PresentOnAdmission, ProblemListFact.PresentOnAdmission<\/p>\n\n\n\n
The core table types in a dimensional data model are facts and dimensions. A row in a fact table corresponds to the occurrence of some significant, measurable event, such as the ordering of a medication or the posting of a charge transaction.<\/p>\n\n\n\n
The core table types in a dimensional data model are facts and dimensions.<\/p>\n\n\n\n
tables and bridge tables. It is possible, but not common, for a dimension table to contain lookup columns to other DMCs.<\/p>\n\n\n\n
A system\u2010generated identifier in Caboodle. Not inherently meaningful to report consumers.<\/p>\n\n\n\n
surrogate key value uniquely identifies one row of the table.<\/p>\n\n\n\n
Unique identifier in the source data. Consists of two columns in Caboodle: IdType and Id. Also known as a business key.<\/p>\n\n\n\n
FOREIGN KEYS in Caboodle end in KEY. They are called LOOKUP Columns. It is a column in a table that joins to another table.<\/p>\n\n\n\n
The columns of a fact table contain relevant metrics and foreign keys, or lookup columns, to link out to entities related to the event.<\/p>\n\n\n\n
unmatched values.<\/p>\n\n\n\n
columns. Column in a table that joins to another table. Points to another table.<\/p>\n\n\n\n
Table-level data lineage can be found in the Sources section of the Caboodle Dictionary for a specific table<\/p>\n\n\n\n
Column-level data lineage for each package is found by expanding that section under the description of each column.
The columns value may reflect the same value as the source, or maybe not and modified by SSIS<\/p>\n\n\n\n
Typically entered in Hyperspace and stored in Chronicle. Data moves from Chronicles to Clarity to Caboodle, so Clarity is a source database for Caboodle.<\/p>\n\n\n\n
Instead of seeing “Clarity” as the source data, non-Epic data sources will show the name of the non-Epic database
For Epic data, columns end in EpicId or EpicCsn<\/p>\n\n\n\n
All lookup columns in Caboodle ending the word KEY. Some lookup columns are foreign keys that they join to the primary key of the destination table.<\/p>\n\n\n\n
A. Users
B. ED Visits
C. Diagnosis definitions
A. Users
C. Diagnosis Definitions<\/p>\n\n\n\n
ED Visits are considered reportable, measurable events and would be in a fact table.<\/p>\n\n\n\n
A. Joining a Fact table to another Fact table
B. Joining a Fact table to a Dimension table
C. Joining a Dimension table to a Dimension table
D. Joining two different Fact tables to the same Profile Dimension table
(Examples may vary)
a. EncounterFact can join to HospitalAdmissionFact
b. MedicationOrderFact can join to PatientDim
c. PatientDim can join to ProviderDim<\/p>\n\n\n\n
A. A single table
B. A single row in a table
A & B<\/p>\n\n\n\n
FALSE<\/p>\n\n\n\n
False. The Caboodle Dictonary contains several lookup columns between two fact tables and between two dimension tables. For example, PatientDim can be joined to ProviderDim and HospitalAdmissionFact can be joined to EncounterFact.<\/p>\n\n\n\n
MedicationOrderKey<\/p>\n\n\n\n
Tables that link to or from a given table are listed under Properties, and hyperlinks to the destination table are provided next to lookup column descriptions.<\/p>\n\n\n\n
Yes. For Example, MedicationOrderFact has a lookup column to EncounterFact.<\/p>\n\n\n\n
MedicationOrderKey stores a surrogate key value generated by Caboodle to identify one row in MedicationOrderFact. MedicationOrderEpicId stores the ID of an order record in Epic, or the ORD.1.<\/p>\n\n\n\n
MedicationKey Stores a surrogate key value generated by Caboodle to identify one row in MedicationDim. MedicationEpicId stores the ID of a medication record in Epic, or the ERX.1.<\/p>\n\n\n\n
False<\/p>\n\n\n\n
False. Assuming the data is extracted to Caboodle, only changes to Type 2 data would generate a new row in PatientDim.<\/p>\n\n\n\n
Type 2 tables have a durable key column which stores the same value for all rows in that table that
correspond to the same entity. This allows for grouping or summarizing data by the entity.<\/p>\n\n\n\n
SELECT DurableKey FROM
Which of the following statements are true?
A. This query will only run if is Type 2
B. This query will run regardless of the Change Type of
C. The value in the DurableKey column could repeat in multiple rows of the results
D. There is no table in Caboodle for which this query will run
a. This query will only run if is Type 2<\/p>\n\n\n\n
There are two change types: Type 1 and Type 2.<\/p>\n\n\n\n
Type 2 = Storing data over time<\/p>\n\n\n\n
Type 1 data reflects the current content of the source as of the last Caboodle extract. In other words, Type 1 tables and columns in Caboodle do not track historical data. When a Type 1 value is updated in the source, all instances of that value in Caboodle are updated the next time the data gets extracted.<\/p>\n\n\n\n
In some cases, Caboodle will keep track of precious values after those values are no longer stored in the original source. Caboodle retains historical values by creating multiple rows for each entity, with each row containing the values for a particular time period. For example, an individual patient may appear in several rows of PatientDim, each representing what Caboodle knew about the patient for a different time period.<\/p>\n\n\n\n
The StartDate column contains the starting date for which the Type 2 data in the row became valid in
Caboodle. For a row that holds the earliest version of the data recorded in Caboodle the StartDate is set to the value of EarliestAllowableDate in the configuration table Config.ConfigurationValues.<\/p>\n\n\n\n
The EndColumn contains the ending date for the range in which the data in the row was valid in Caboodle. For a row that holds the most recent version of the data occurring in Caboodle the EndDate is set to the value of the LatestAllowableDate in the configuration table Config.ConfigurationValues.<\/p>\n\n\n\n
A durable key is a system\u2010generated identifier that facilitates grouping the rows in a Type 2 table by the entity they represent. For example, each time an employee changes jobs, a new row is created in
EmployeeDim. Every employee would be assigned a single durable key value which is then populated on each of their rows in EmployeeDim.<\/p>\n\n\n\n
refer to the same entity in a table<\/p>\n\n\n\n
Ends in DurableKey: joins to DurableKey column<\/p>\n\n\n\n
Many tables in Caboodle reference patients, providers, and employees. PatientDim, ProviderDim, and EmployeeDim are Type 2 tables in Caboodle.<\/p>\n\n\n\n
This is documented in the table Properties in the Dictionary.<\/p>\n\n\n\n
In the Caboodle dictionary it lists if the column is type 2<\/p>\n\n\n\n
If the data is type 1, all values overwrite old values. If the data is type 2, new data will be created<\/p>\n\n\n\n
The durable key lookup columns can also be used to aggregate rows for the same entity without joining to the dimension at all. For example, to count the number of encounters for each patient in EncounterFact, apply a GROUP BY using PatientDurableKey.<\/p>\n\n\n\n\n
Foreign keys reference the row that was current at the time of extract<\/p>\n\n\n\n
Type 2 column values track historical data, Type 1 column values reflect the current source data. Type 1 data is overwritten in Type 2 tables to reflect current source data. Only changes to Type 2 are tracked.<\/p>\n\n\n\n
There would be an inferred row in ProviderDim, therefore ProviderDim.Name would show “*Unknown” for the encounter.<\/p>\n\n\n\n
There are two possibilities: Either the data that once populated this row in Caboodle has been deleted from the source or this is the row with \u20103 as its primary key, for which all foreign key columns are also \u20103. To know which is true, check the primary key value for the given row: a non\u2010negative value indicates that this row represents deleted data in the source.<\/p>\n\n\n\n
If the foreign key was null in the source, then a \u20101 will appear in Caboodle to represent an unspecified value. If the foreign key’s data lineage was not defined by the source package that loaded data for a particular row, then a \u20102 will appear in Caboodle to represent a value that is not applicable.<\/p>\n\n\n\n
A. \u20102
B. NULL
C. 12\/31\/1840
D. *Not Applicable
b. NULL<\/p>\n\n\n\n
store ‘*Not Applicable’, and all other data type columns will store NULL.<\/p>\n\n\n\n
False
Inferred rows in Caboodle have non\u2010negative primary key values because they represent an entity that Caboodle has inferred the existence of. The foreign key columns for such rows will be set to \u20101 until the Caboodle ETL process updates the data.<\/p>\n\n\n\n
Referential integrity is enforced in Caboodle, meaning that lookup columns will never contain null values. Furthermore, every value in a lookup column has a match in the destination table.<\/p>\n\n\n\n\n
When a foreign key value is loaded into Caboodle, the ETL process uses its Id and IdType to determine the correct surrogate key value to store. If the referenced row does not exist yet, the ETL process creates a new row in the target table and assigns a new surrogate key value as its primary key. Such a row is called an inferred row.<\/p>\n\n\n\n
Two common scenarios:
A. Unmatched references in the source
B. Testing or development<\/p>\n\n\n\n
These rows provide a place for foreign keys to point.<\/p>\n\n\n\n
AS PART OF REFERENTIAL INTEGRITY<\/p>\n\n\n\n
(Unspecified Foreign Key)<\/p>\n\n\n\n
foreign keys to the DateDim table, NULL dates from Clarity are often represented with a \u20101 value DateKey
columns in Caboodle.<\/p>\n\n\n\n
AS PART OF REFERENTIAL INTEGRITY<\/p>\n\n\n\n
AS PART OF REFERENTIAL INTEGRITY<\/p>\n\n\n\n
Caboodle tracks the deletion in one of two ways.<\/p>\n\n\n\n
Every bridge table has a ComboKey to which other tables join and a Foreign Key used to join to its associated dimension table.<\/p>\n\n\n\n
True
The AttributeValueDim tables can store multiple attribute\u2010value combinations on separate rows
for the same entity, making them more granular than their associated fact table<\/p>\n\n\n\n
Bridge tables exist to capture many\u2010to\u2010many relationships, such as the one between patients and the diagnoses on their problem list.<\/p>\n\n\n\n
The entity-attribute-value (EAV) framework allows you to essentially add data to existing Caboodle tables without changing the structure of those tables.<\/p>\n\n\n\n
Both Bridge tables and MappingFact tables are used to map many\u2010to\u2010many relationships. However, Bridge tables use a combo key as part of their definition and always link to a single dimension table while MappingFact tables may link to one or more fact or dimension tables.<\/p>\n\n\n\n
One form of EAV data in Caboodle is the AttributeValueDim DMCs. These tables contain attribute\u2010value pairs and can be created for different entities. For instance, there is the PatientAttributeValueDim table to go along with PatientDim, or the DepartmentAttributeValueDim table to go along with DepartmentDim.<\/p>\n\n\n\n
In the context of Caboodle, data marts are, broadly, collections of Caboodle data on a topic. Some data marts serve as comprehensive data sources for a particular reporting need, making it easier for business intelligence developers to write reports. For example, the HospitalReadmissionAnalyticsDataMart contains all the data relevant for predicting the likelihood of a future hospital readmission.<\/p>\n\n\n\n
events and refer to data in dimension tables.<\/p>\n\n\n\n\n
STORES GROUPER INFORMATION
In Chronicles, the VCG master file stores groupers, which are lists of Chronicles records (most commonly), ICD codes, or other concepts used together frequently in Hyperspace. VCG groupers are maintained by application analysts in Hyperspace, but can be useful for writing Caboodle reports as well.<\/p>\n\n\n\n
CHOOSE ONLY ONE ANSWER
A. dbo schema on staging database
B. dbo schema on the reporting database
C. Epic schema on either database
D. FullAccess schema on the reporting database
D. FullAccess schema on the reporting database<\/p>\n\n\n\n
TRUE
Caboodle is customizable, meaning your organization can bring in additional data from Clarity as well as third party sources.<\/p>\n\n\n\n
CHOOSE ONLY ONE ANSWER
A. When no PHR record ID exits, PharmacyKey stores -1 and PharmacyEpicId is null
B. When no PHR record ID exits, PharmacyKey is null and PharmacyEpicId is -1
C. PharmacyKey uniquely identifies a row in PharmacyDim; PharmacyEpicId stores the PHR record ID
D. PharmacyKey stores the PHR record ID; PharmacyEpicId uniquely identifies a row in PharmacyDim
C. PharmacyKey uniquely identifies a row in PharmacyDim; PharmacyEpicId stores the PHR record ID.<\/p>\n\n\n\n
CHOOSE ALL THAT APPLY
A. The column is marked as Type 2
B. The ER diagram lists it as a foreign key
C. The column is contained in a fact table
D. The destination table is listed to the right of the column description
B. The ER diagram lists it as a foreign key
D. The destination table is listed to the right of the column description<\/p>\n\n\n\n
CHOOSE ONLY ONE ANSWER
A. Only Table A
B. Only Table B
C. Both Table A and Table B
D. Neither Table A nor Table B
B. Only Table B
Inferred rows are created in the table that is referenced by a foreign key’s value. When data is loaded into table A, it’s foreign key is populated. If Table B does not yet have that foreign key value, and inferred row is created.<\/p>\n\n\n\n
CHOOSE ALL THAT APPLY
A. The foreign keys will store -1
B. The foreign keys will store “Unspecified”
C. The foreign keys will store “Unknown”
D. Columns with a data type of varchar will store “Unspecified”
A. The foreign keys will store -1
D. Columns with a data type of varchar will store “Unspecified”<\/p>\n\n\n\n
A. Fact
B. Dimension
C. SetDim
D. DataMart
E. AttributeValueDim
F. Bridge
Bridge
Although it is the destination of the join, the combo key column of a bridge table is not the primary key. Rather, multiple rows may have the same combo key value.<\/p>\n\n\n\n
The level of detail for one row in the table.<\/p>\n\n\n\n
The Primary Key is the column(s) that can uniquely ID a row in a table.<\/p>\n\n\n\n
Surrogate Key is a key where the values don’t exist in the source data. These values are NOT in Clarity. They are generated in the ETL process\u2026They are created when moved.<\/p>\n\n\n\n
Each DMC gets a type. Strict table naming conventions are followed in Caboodle, so that a table’s suffix provides information about its structure and purpose. These suffixes are:
\u00b7 Dim for dimensions (e.g. PatientDim)
\u00b7 Fact for facts (e.g. EncounterFact)
\u00b7 Bridge for bridges (e.g. DiagnosisBridge)
\u00b7 DataMart for data marts (e.g.HospitalReadmissionDataMart)
\u00b7 AttributeValueDim for EAV tables (e.g. PatientAttributeValueDim)
\u00b7 X for custom tables .e.g. CustomFactX<\/p>\n\n\n\n
An entity\u2010relationship diagram, or ER diagram, is a visual tool that displays information about how database objects relevant to a particular reporting area join to one another. Caboodle ER diagrams are automatically generated for fact tables and data mart tables in the dictionary.<\/p>\n\n\n\n
A surrogate key is any column or set of columns that can be declared as the primary key instead of a “real” or natural key. Sometimes there can be several natural keys that could be declared as the primary key, and these are all called candidate keys. So a surrogate is a candidate key.<\/p>\n\n\n\n
Contact Serial Number<\/p>\n\n\n\n
Type 1 tables and columns in Caboodle do not track historical data. When a Type 1 value is updated in the source, all instances of that value in Caboodle are updated the next time the data gets extracted.<\/p>\n\n\n\n
Caboodle retains historical values by creating multiple rows for each entity, with each row containing the values for a particular time period.<\/p>\n\n\n\n
A. A surrogate key that acts as the primary key of the table.
B. Count column
C. Zero or more foreign keys
D. A DurableKey column
A: A surrogate key that acts as the primary key of the table
C: Zero or more foreign keys<\/p>\n\n\n\n
A. Caboodle enforces refrential integrity
B. Some Caboodle tables use change tracking.
C. Caboodle uses the dimensional data models
D. Caboodle uses the entity-attribute-value data model
B: Some Caboodle tables use change tracking<\/p>\n\n\n\n
The IsCurrent column is a flag that stores the value of 1 if the row holds the most current information and 0 otherwise.<\/p>\n\n\n\n
SELECT EncounterEpicCsn, AdmittingProviderKey, DischargingProviderKey
FROM HospitalAdmissionFact
WHERE and AdmittingProviderKey >0 and DischargingProviderKey >0
CHOOSE ONLY ONE ANSWER
A. AdmittingProviderKey = DischaringProviderKey
B. AdmittingProviderDurableKey = DischargingProviderKey
C. AdmittingProviderDurableKey = DischargingProviderDurableKey D. All of the above are equally valid
C. AdmittingProviderDurableKey = DischargingProviderDurableKey<\/p>\n\n\n\n
Caboodle uses three mechanisms for enforcing referential integrity:
\u00b7 Every table in Caboodle contains three rows with surrogate keys of \u20101, \u20102, and \u20103. These rows serve as the destination for lookup columns in other tables.
\u00b7 When source data is unavailable to populate a lookup column, Caboodle supplies a default value of \u20101, \u20102, or \u20103. Which value is used depends on the circumstance behind the missing information.
\u00b7 When data loaded in one Caboodle table is more up\u2010to\u2010date than data in another table, the Caboodle ETL process generates an inferred row in the delayed table. This row represents the entity being referenced by the more up\u2010to\u2010date table. Inferred rows act as place holders until the relevant information is loaded into Caboodle.<\/p>\n\n\n\n
When a foreign key value is loaded into Caboodle, the ETL process uses its Id and IdType to determine the correct surrogate key value to store. If the referenced row does not exist yet, the ETL process creates a new row in the target table and assigns a new surrogate key value as its primary key. Such a row is called an inferred row.<\/p>\n\n\n\n
When an inferred row is created, all its string values are set to *Unknown. Additionally, all of the inferred row’s foreign key columns are assigned a value of \u20101 and any remaining data columns are set to NULL.
The inferred row is a placeholder, so a later ETL will update these default values when that information is populated in the source database, regardless of the table’s change type<\/p>\n\n\n\n
Entity Attribute Value
The three major components of the EAV data model are entities, attributes, and values.<\/p>\n\n\n\n
A business key is an identifier for a record in Caboodle. The business key is a combination of column identifies a record, and is based on source system identifiers. For example, a business key could consist of a patient’s ID number and an ID type column identifying the number as an MRN. In other words, the business key is tied to the actual extracted data, unlike a surrogate key. For reporting efficiency, durable and surrogate keys should be used in reports instead of business keys.<\/p>\n\n\n\n
The data lineage is a precise technical explanation of where data in a package is extracted from in a source database. This explanation can be as simple as a source table and column in Clarity or much more logically complex as in the following ex:
(see doc @ https:\/\/galaxy.epic.com\/?#Browse\/page=1!68!50!3517622&from=Galaxy-Redirect)<\/p>\n\n\n\n
A durable key is an identifier for a record in Caboodle, shared across rows for the same record. Unlike a business key, a durable key consists of a single column and isn’t derived or extracted from the source data. For example, because patient data is tracked over time, a single patient record might have multiple rows associated with it in PatientDim. Each row has the same durable key to make it easy to find all rows with a particular patient. Durable keys are used only in tables that store snapshot (type 2) data.<\/p>\n\n\n\n
A foreign key is the primary key for a row in a different table in Caboodle, used to link two tables together. For example, ProcedureOrderFact contains a PatientKey column, which corresponds to the surrogate key in PatientDim. Business intelligence developers use foreign keys to write reports using data from multiple tables.
For ease and efficiency of report writing, foreign key columns in Caboodle have refrential integrity. In other words, foreign key columns never contain null or unmatched values.<\/p>\n\n\n\n
When a foreign key value is expected but its value is null in the source system, the foreign key is said to be unspecified. In this case, the corresponding foreign key in Caboodle is set to -1. For example, suppose a patient hasn’t been assigned a primary care physician. When the patient’s record is loaded into Caboodle, the PrimaryCareProviderKey column is set to -1. That column would then join to the -1 row in the ProviderDim table.
Foreign keys also refer to the -1 row for inferred data. For example, suppose your organization hires a new physician, and that physician is assigned as a patient’s primary care provider. If the patient’s record is loaded into Caboodle before the new provider’s record, it contains a foreign key reference to a row that doesn’t yet exist, but is expected to be loaded eventually. In this case, Caboodle makes a new inferred row in ProviderDim for the expected provider. When the new provider’s information is eventually loaded into Caboodle, its values overwrite the default values that were assigned to the inferred row.
When a foreign key doesn’t apply for a certain row, the foreign key is said to be not applicable. In this case, the corresponding foreign key in Caboodle is set to -2. For example, BillingAccountFact contains information related to both hospital billing accounts and professional billing accounts. Only hospital billing accounts have admitting providers for the hospital encounter, so rows for professional billing accounts have AdmittingProviderKey set to -2.
When a row in Caboodle is marked as deleted, the surrogate key isn’t hard-deleted from your database. Instead, all strings are replaced with *Deleted, foreign keys are set to -3, and other columns have null values.<\/p>\n\n\n\n
A surrogate key is a unique identifier for a row in Caboodle, and is also a table’s primary key. Unlike a business key, a surrogate key isn’t derived or extracted from the source data. Instead, it’s applied in Caboodle. Unlike a durable key, each row has a different surrogate key.<\/p>\n\n\n\n
A snapshot column tracks changes to data in the column by creating a new instance of the row each time data in the column changes. A snapshot DMC contains one or more snapshot columns. For example, if you use snapshot data for columns related to a patient’s address, a new row for the patient is created each time the patient’s address changes.
If a column or DMC isn’t marked as snapshot, it doesn’t track changes over time and stores only the most recent information for a record. If the data changes, it overwrites the previous value. For example, if you don’t track changes to a column for a patient’s Social Security number, any changes to a patient’s SSN overwrite the previous value in existing rows for the patient.
Snapshot data represents information at a particular point in time. The dates associated with this snapshot aren’t clinically relevant because the dates correspond with when the data was loaded into Caboodle, not when an event actually occurred or was changed in an upstream system like Chronicles. When you write reports, never treat snapshot data as historical clinical data.
Prior to August 2020, snapshot data is called type 2 data, and other data is called type 1 data.<\/p>\n\n\n\n
A DMC is a Caboodle-specific concept that refers to a table in the Caboodle reporting database and its supporting infrastructure. DMCs can be facts, dimensions, bridges, data marts, or informational tables.<\/p>\n\n\n\n
Fact tables hold all the measures in Caboodle. These are the primary tables that contain the many rows of data created in the source system, such as individual encounters, orders, and transactions. These facts are typically joined to multiple dimensions to add extra information that helps define the facts. These clusters of facts with multiple dimensions make up the star schema on which a dimensional data warehouse is built. In general, fact tables in Caboodle contain numeric data and link to dimensions and profile dimensions for other information.<\/p>\n\n\n\n
A dimension is a table in Caboodle that contains attributes describing one or more facts. Dimensions are joined to facts to provide descriptive information about them. For example, PatientDim contains patient information that applies to many DMCs.<\/p>\n\n\n\n
A bridge is a table that stores information where many-to-many relationships are common. For example, consider diagnoses and patient records. Each type of record might be related to many of the other type: a patient can have multiple diagnoses, and a diagnosis can appear on many patients. In a bridge table, each key references a unique combination of records that exists in your organization’s extracted data. This method of storage helps improve performance because if multiple patient records have the same associated diagnoses, the combination of diagnoses appears only once instead of many times.<\/p>\n\n\n\n
A data mart is a collection of Caboodle data on a topic. Some data marts serve as comprehensive data sources for a particular reporting need, making it easier for business intelligence developers to write reports. For example, the HospitalReadmissionAnalyticsDataMart contains all the data relevant for predicting the likelihood of a future hospital readmission. Data marts are very similar to fact tables because they both store data about significant, measurable events and refer to data in dimension tables. However, data marts can do direct key lookup to retrieve data, which means they can link to other tables using a single Key row instead of two rows for the ID and ID type.<\/p>\n\n\n\n
Running your reports with snapshot isolation level ensures the reports and Caboodle executions don’t interfere with each other.<\/p>\n\n\n\n
This schema simplifies your reports by aggregating the information you find in facts, profile dimensions, and bridge tables. It also includes only the data that passes Caboodle’s data quality checks, which are available starting in August 2018. If you use the dbo schema, reports can include data that’s considered invalid.<\/p>\n\n\n\n
https:\/\/galaxy.epic.com\/?#Browse\/page=8400!68!280!4022506,4022507,4022508<\/p>\n","protected":false},"excerpt":{"rendered":"