Optum ZIP5

#Section 2 **Member** - The Member table contains aggregated eligibility information. Each span of eligibility information for a member will have one row. There may be multiple rows per member. Breaks in eligibility will trigger a new row, representing different eligibility and effective dates. Changes in other variables will not trigger the creation of a new row in the Member table. All other variables, such as plan type or state, will be populated based on the entries valid for the last effective date. - The Member Detail table also contains member eligibility data. However, this table will have a new row each time any information about the member changes, such as state or product. The Member Detail table will have more rows than the Member table so that changes in information other than eligibility dates can be captured. This table is useful if you are looking at a variable that might change over time such as state or product. Many members will be represented multiple times in the Member Detail table with different information. Use the eligibility dates to choose the appropriate row that matches the date of service of the relevant claim. - Sometimes, enrollment periods overlap each other. It is possible for a member to have more than one insurance product at a time. For example, a member might have both primary and supplemental insurance. When the time periods overlap, there is no clean link between the claims and the eligibility table because there could be multiple rows returned in a match. To solve this problem, the Member Detail table has a column called PAT\_PLANID, which will be a link to the relevant row. - If you are using the Member table (versus Member Detail), then link to the other tables by PATID. If using the Member Detail table, link to other tables by using PAT\_PLANID which identifies both member and product of the eligibility table. In general, queries requiring member information will contain either the Member or Member Detail table, not both. - There is a process within our source system that will validly reassign a PAT\_PLANID to a PATID. Someone is most likely to be reassigned a PAT\_PLANID when the person was a previous member and already had a PATID associated with them. Then we re-assign them to the earlier ID so that we can maintain the claims history for that member. The previous claims are not updated with the new information, but the member tables are. You still are able to match the claims to Member Detail using the PAT\_PLANID as stated above. Because of this possibility, the PATID should be selected from the Member Detail table and not from the Medical Claims table. - After 2006, Medicare patients were excluded from the CDM. - Patients who are 65 years and are still recorded in the CDM are patients with commercial insurance, receiving benefits via a spouse who is still working **Member Detail** - Unlike the Member table, there may be multiple rows per eligibility period. There is a new row for a member each time any information about the member changes (i.e., state, product). - Information to this table should be linked with variable: PATID or PAT\_PATID (for members on multiple plans at same time) - The Member Detail table also contains member eligibility data. However, this table will have a new row each time any information about the member changes, such as state or product. The Member Detail table will have more rows than the Member table so that changes in information other than eligibility dates can be captured. This table is useful if you are looking at a variable that might change over time such as state or product. - Many members will be represented multiple times in the Member Detail table with different information. Use the eligibility dates to choose the appropriate row that matches the date of service of the relevant claim. When looking at continuous enrollment, keep the multiple rows in mind. In the example above, the member has continuous enrollment from January 2005 to December 2007, but you would need to look at multiple rows in Member Detail to calculate that span. Or, the Member table with the simpler structure will have continuous eligibility in one row. - Sometimes, enrollment periods overlap each other. It is possible for a member to have more than one insurance product at a time. For example, a member might have both primary and supplemental insurance. When the time periods overlap, there is no clean link between the claims and the eligibility table because there could be multiple rows returned in a match. To solve this problem, the Member Detail table has a column called PAT\_PLANID, which will be a link to the relevant row. - If you are using the Member table, then link to the other tables by PATID. If using the Member Detail table, link to other tables by using PAT\_PLANID which identifies both member and product of the eligibility table. In general, queries requiring member information will contain either the Member or Member Detail table, not both. - There is a process within our source system that will validly reassign a PATPLANID to a PATID. Someone is most likely to be reassigned a PATPLANID when the person was a previous member and already had a PATID associated with them. Then we re-assign them to the earlier ID so that we can maintain the claims history for that member. The previous claims are not updated with the new information, but the member tables are. You still are able to match the claims to Member Detail using the PAT\_PLANID as stated above. Because of this possibility, the PATID should be selected from the Member Detail table and not from the Medical Claims table. - After 2006, Medicare patients were excluded from the CDM. - Patients who are 65 years and are still recorded in the CDM are patients with commercial insurance, receiving benefits via a spouse who is still working **Medical Claims** - The Medical Claims table contains medical claims data for inpatient and outpatient professional services including services such as outpatient surgery, laboratory, and radiology. This table contains information specific to professional claims (coded with CPT©/HCPCS Level II Codes) and facility claims. Included within this table are revenue codes, procedure codes, ICD-9 or ICD-10 diagnosis codes, provider category codes, and place of service codes. - The Medical Claims table has some variables to identify if a member has complete coverage, or if there is supplemental insurance involved. For some analyses, it’s critical to know if the claims represent a complete claim picture. Knowing if there is supplemental insurance involved helps you know if the claims involved are complete. - At the current time, Co-ordination of Benefits (COB) is populated since 2009. In the years prior to 2009, COB variables will be empty. - The Medical Claims table has an ICD\_FLAG to indicate whether the version of the claim is ICD-9 or ICD-10. ICD-10 is a comprehensive and detailed list of codes to more specifically define both the diagnoses and procedures on the claim than ICD-9. When a claim is submitted, it will either be ICD-9 or ICD-10. All diagnosis and ICD procedure codes on the claim will either be ICD-9 or ICD-10. A claim will not have a mix of old and new codes. - There are a total of twenty-five diagnosis codes, inpatient procedure codes, and present on admission codes. With ICD-10 codes, providers tend to use more diagnostic codes. New procedure codes contain more information, such as where on the body the service was performed. - The Present on Admission (POA) variable will contain information on all of the twenty-five ‘present on admission’ codes concatenated together with ‘.’ as a delimiter. You can split the string into 25 separate variables using the delimiter. Three values are valid, namely, Y (for present on admission), N (for not present), and U (for unknown or not applicable.) An example of a value would be: `Y.Y.Y.N.Y.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U`. In this example, the fourth diagnosis was not present on admission, and so was acquired in the hospital. - There are four variables containing provider information. The variable PROV was the only provider included in previous versions of the CDM and will still be included for consistency with older code. In addition, the referring provider (REFERPROV), the servicing/attending provider (SERVICEPROV), and the billing provider (BILL\_PROV) are included on each row in the medical claim. - Denied Claims in the Medical TableDenied medical claim lines are included in the medical table. PAID\_STATUS, will indicate whether the claim line was paid or denied. Denied medical claims typically represent services that are provided to the member, but not paid by the insurer. Including these claims give a more complete picture of the total care, including better measures of complete disease burden. It also gives some insight into treatments that might not be covered by the insurer for whatever reason. - A claim can have multiple claim lines. Each claim line will have its own PAID\_STATUS. One line can be PAID and another line DENIED for the same claim number. If ALL claim lines are DENIED for a claim, none of the claim lines will be included in the CDM. If at least one claim line is PAID, then all claim lines are included in the CDM. - Denied pharmacy claims are not currently included in the data. **Pharmacy Claims** - The Pharmacy Claims table contains claims submitted by pharmacies for prescriptions filled on an outpatient basis. Included in this table are NDC codes (NDC), medication brand names (BRND\_NM), generic classifications (GNRC\_IND), medication strength (STRENGTH), quantity prescribed (QUANTITY), days supply (DAYS\_SUP), charges (CHARGE), co-pays (COPAY), dispensing fees (DISPFEE), and standardized costs (STD\_COST). - The Pharmacy Claims Table does not contain drugs dispensed during inpatient stays. - Data duplicates may happen. - Uses standard pricing methodology (to account for differences in pricing across health plans, provider contracts). Costs normalized 2013 $USD. **Facility Detail** - Facility detail claims give a more granular level of information on services performed in an inpatient setting. This can include better information on drugs administered or lab tests performed. This data is not complete as it’s not captured by all of the internal upstream data providers; however, facility detail is captured for roughly 80% of inpatient claims. - The standard cost on the detail lines should not be added to the total standard cost. They represent a breakdown of the costs represented in the medical table. **Inpatient Confinement** - The Inpatient Confinement table contains a summarized record for each inpatient episode occurring in an acute care hospitalization or skilled nursing facility setting. - There is a unique record for every hospitalization observed during the data period. In this unique confinement record, all facility detail records are bundled and reported in a single unduplicated row. Included in the record are the admission date (ADMITDATE), discharge date (DISCHDATE), length of stay (LOS), primary diagnosis (DIAG1), provider ID (PROV), place of service (POS), discharge status (DSTATUS) and standardized cost (STD\_COST). - There are up to five ICD-9 diagnosis codes entered into the Inpatient Confinement table (DIAG1-DIAG5). The variable DIAG1 is typically considered the primary diagnosis. - Each row represents a single hospitalization. By using the confinement ID (CONF\_ID), it is possible to obtain claims for those professional services that have been rendered and billed separately during the confinement period from the Medical Claims table. In a limited number of cases, no records will be found in the medical table to correspond with the confinement. Sometimes a medical claim will be denied after having been paid and included in the CDM long enough for the confinement to be built. When this happens, the medical claims are no longer be included in Data Mart, but the confinement ID still exists. - If the patient is transferred to a different facility or different acuity setting within the same facility (e.g., from acute care to rehab care), each hospitalization has a different confinement record including a separate Confinement ID (CONFID), admit date (ADMITDATE), discharge date (DISCH\_DATE), and length of stay (LOS). - A standard delivery of CDM will contain 13 Quarters (39 months) of Confinement data (as well as Medical data, which includes the CONF\_ID). This is an extended period of time than what is normally delivered for the other types of data as confinement claims are more sensitive to adjustments and the longer time period increases the stability of the data set. - Uses standard pricing methodology (to account for differences in pricing across health plans, provider contracts). Costs normalized 2015 $USD **Provider** - Provider information is in two tables, PROVIDER, and PROVIDER\_BRIDGE. - The variable, PROV\_UNIQUE uses business intelligence to group the providers ids (BILL\_PROV, REFER\_PROV, SERVICE\_PROV, PROV) into unique physicians or facilities. PROV IDs are traditionally difficult to work with as some providers are assigned multiple ids within our affiliate company’s claim processing system. This makes it difficult to do any analysis based on provider care. While PROV\_UNIQUE cannot completely solve this problem, it takes advantage of known information to consolidate provider IDs into a better identifier of particular providers. - The PROVIDER table also includes variables to denote provider specialty, TAXONOMY1 and TAXONOMY2 and PROVCAT. PROVCAT is defined by our affiliate company in the claim processing system. TAXONOMY is defined federally by the National Uniform Claim Committee. Two TAXONOMY variables are included so multiple licensures can be documented. **Provider Bridge** - The Provider Bridge table includes all of the relevant ID variables used in different tables. PROV from the medical table and NPI and DEA from the pharmacy tables all link to the new Provider Bridge table. Then, the Provider Bridge table can be used to link to the Provider table to get the information such as credentials or specialty information. - The table also allows the providers in the pharmacy and medical claims to be linked together. **Laboratory Test Results** - The Laboratory Test Results table contains laboratory test results for all available lab tests. - Outpatient lab tests processed by national lab vendors under contract with MCO. - The database only contains laboratory tests performed within certain laboratory networks. Therefore, it will not contain every lab result for every member. Some members may not have lab results included in the data at all, and for those members with lab results there is no assurance the lab tests are complete. - Included in this table are LOINC codes (LOINCCD), high normal ranges (HINRML), low normal ranges (LOWNRML), lab test descriptions (TESTDESC), and lab results in numeric (RSLTNBR) and text (RSLTTXT) format.