Download:
pdf |
pdfMCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
BASE
Section
collected
Important fields
RECORD DELETE
FLAG?
FK?
Preloaded
SAMPTYPE
Indicates the SP's sample when entering study. Not referenced in instrument specs.
Preloaded
EXITRND
(EXITRND - 1) indicates the last round SP will be in sample. The EXIT round is always a Summer Round.
Not referenced in instrument specs. Instead, MRES.INTTYPE = 8 or 9 indicates the SP in their exit round.
Preloaded
SPDOBMM/DD/YY
SPSEX
HS flags
SP's DOB and gender from CMS is loaded on BASE and then verified in Introduction (IN) in the SP's first
community interview (MRES.INTTYPE = 2 or 3). The SP's DOB is then copied to ROST.
When fielding the fall round supplement, Health Status and Functioning (HF), we set flags on BASE which
indicate which questions have already been asked in prior round HF sections. The flags stored on BASE
affect the routing in the current Fall round HF section.
Preloaded
LASTEVNT
LASTCOST
LASTREIM
LASTTRNS
Highest record numbers for EVNT, COST, REIM and TRNS. Used to determine which next sequential #
should be used when creating new records in the instrument.
Preloaded
MRESRND
Part of Key. Is used to identify the ROUND # being administered.
Preloaded
MRESRESP
Part of Key. Is always set to "01" for community interview. "02" through "99" is reserved for facility
interviews.
Preloaded
MRND
MRES
NOT USED IN TESTING
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM1 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Preloaded
Important fields
INTTYPE
RECORD DELETE
FLAG?
FK?
Current round interview type:
1 StandardHadPrev
Most common interview type. SP received a community interview in the previous
round.
2 NewFromFacility
interview.
SP's previous round interview was in a facility. SP has never had a community
3 NewFromSupplement SP's first round community interview, the 1st round SP is in study. Fall round
only.
4 StandardSkippedPrev SP's last interview was in the community 2 rounds ago. SP skipped previous
round.
5 LastRndFacSum
rounds ago.
SP's previous round interview was in a facility. SP had a community interview 2
6 LastRndFacBase
rounds ago.
SP's previous round interview was in a facility. SP had a community interview 3 +
7 SupSmp1stTimeUtil SP's 2nd round in the study. SP is being administered the utilization sections for
the 1st time. Winter round only.
8 ExitInterviewHadPrev
only.
SP's last round interview. SP had a previous round interview. Summer round
9 ExitInterviewSkippedPrev
Summer round only.
SP's last round interview. SP skipped the previous round interview.
10 SupSmp1stTimeUtilSkipped
SP's 2nd round in the study. SP skipped the previous round. SP is
being administered the utilization sections for the 1st time.
Summer round only.
Preloaded
Preloaded
PREVCOM1
PREVCOM2
MREFDATE
REFERENCE DATE.
Typically is set to the date of the previous round interview and is used to collect new data since the
previous round interview date.
"REFERENCE DATE" to "TODAY/DATE OF DEATH/DATE OF INSTITUTION" is used to define the
current round data collection time period.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM2 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Preloaded
Important fields
SUMMBDAT
RECORD DELETE
FLAG?
FK?
SUMMARY REFERENCE DATE.
Typically set to the previous round MREFDATE and is used in SUMMARY sections to collect/update data
collected for the previous round data collection time period.
"SUMMARY REFERENCE DATE" to "REFERENCE DATE" is used to define the summary section data
collection time period in UTS, HIS, PMS.
Preloaded
SRPBDAT
SURVEY REFERENCE DATE.
Typically set to 2 rounds previous MREFDATE and is used in COST sections to collect charge data for the
past year.
"SURVEY REFERENCE DATE" to "TODAY/DATE OF DEATH/DATE OF INSTITUTION" is used to define
the Cost series data collection time period in ST, PS, NS and CPS.
Calculated by
program
Calculated by
program
IN
Round Type - TEMP
Previous Round - TEMP
WVS specific calculated round type: FALL, WINTER, SUMMER. Is used in routing instructions to
determine which sections/questions are asked depending on which round is being administered.
WVS specific calculated previous round based on MRES.INTTYPE.
Previous round = (CURRENT ROUND - 2) if SP skipped previous round (MRES.INTTYPE = 4, 9, 10).
Else Previous round = (CURRENT ROUND - 1).
SPALIVE
SP's status if first collected into a temporary field, SPAISTATUS, which has response options 1 thru 4.
MRES.SPALIVE is set in the background based on SPAISTATUS:
If SPAISTATUS = 4, set MRES.SPALIVE = 2.
Else MRES.SPALIVE = SPAISTATUS.
MRES.SPALIVE =
1 Alive
2 AliveAndInstitute
3 Deceased
MRES.SPALIVE is not asked for Supplemental Sample. Therefore MRES.SPALIVE = empty typically
follows the same path as MRES.SPALIVE = 1/Alive.
IN
SPINSTMM
SPINSTDD
SPINSTYY
Date of institutionalization.
IN
SPDIEMM
SPDIEDD
SPDIEYY
Date of death.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM3 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Important fields
SPPROXY
IN
RROSTNUM
FK
ROST.ROSTNUM for respondent.
ROST.RROSTNUM = 01 if SP is the respondent.
If Proxy interview, Proxy is added/selected from Person Roster and MRES.RROSTNUM is set to Proxy's
ROST.ROSTNUM.
IN
RADDRNUM
FK
ADDR.ADDRNUM for last ADDR collected for respondent. IS THIS STILL BEING USED?
Breakoff, CL/EX
MRESBDAT
MRESEDAT
MENDDATE
Beginning of
Interview
Global
EVRESTRT
TEMP - LASTRESP
TEMP - LASTSTATUS
TIME STAMPS
RCON
ROST
FK?
IN
Breakoff, CL/EX
HOME
RECORD DELETE
FLAG?
Respondent is SP or Proxy
1 SP
2 Proxy
FK
These fields stamp the date the interview was first accessed in a round, the last date the interview was
accessed.
Stores the current round reference end date (i.e. MRESEDAT, Date of Death, or Date of Institution). Verify
this information.
Set in Introduction when restarting interview.
Set's MRES.EVRESTRT = 1 that flags that the case is a RESTART.
Set's LASTRESP and LASTSTATUS before collecting new Respondent and SP's Status.
MRES stores the Cheshire Time stamps. Not currently used by WVS.
NOT USED IN TESTING
ENS
(OLD EN)
SPAFEVER
SPNGEVER
SPAFEVER = 1 or SPNGEVER = 1 indicates SP served in Armed Forces.
Is collected in SP's first community interview in ENS (INTTYPE = 2 or 3).
Is referenced in later rounds when determining whether or not to ask HIT11 - MTFCOVER and HI36 VACOVER.
AV
MSTADDR1
MSTADDR2
MCITY
MSTATE
MZIPCODE
SP's mailing address. Is collected/updated each round in AV section.
IN, ENS, Global
ROSTNUM
Part of Key. Person number.
IN, ENS, Global
ROSTFNAM
ROSTMINI
ROSTLNAM
First Name, Middle initial, Last Name.
IN, ENS, Global
ROSTREL
ROSTRELOS
ROSTSEX
Relationship to SP
HHDOBMM
HHDOBDD
HHDOBYY
Date of Birth
IN, ENS
IN, ENS
Middle Initial is only collected for SP.
Gender
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM4 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
ENS
Important fields
ADDR
FK?
ENSFLAG
PROVNUMR
ENUM
RECORD DELETE
FLAG?
Used to determine route to ENS10. If Person is missing DOB or Gender, ENS10 prompts for updates.
ROST.ENSFLAG is set to 1 when ENS10 is asked so that ENS10 is not asked again in a later round.
FK
PROV.PROVNUM - no longer used?
ENS
ENUMROST
ENS
ENUMRND
Part of Key. Person number. Matches person's ROST.ROSTNUM.
Part of Key. Round # in household.
ENS
NOTHHRSN
If the person was in the household in the previous round and is reported as "no longer in the Household" in
the current round, a current round ENUM record is generated and the reason why the person is no longer
in the household ist stored on ENUM.NOTHHRSN.
ENS
First Name, Last Name
ENS
ENUMFNAM
ENUMLNAM
HHPREL/HHPRELOS
ENS
HHPSEX
Gender
ENS
HHDOBMM/DD/YY
Date of Birth
ENS
HHPAGE
Calculated based on date of birth or can entered if Date of Birth = DK, RF.
Relationship to SP
AV, CL
ADDRROST
Part of Key. Person number. Matches person's ROST.ROSTNUM.
AV, CL
ADDRNUM
AV, CL
ADDRRNDC
Part of Key. Sequential number. The most recent ADDR collected for a person will be stored on the
highest ADDRNUM.
Round # ADDR created. SP and Proxy will automatically have an ADDR created where
ADDR.ADDRRNDC = current round. All updates will be written to this record. A person may not always
have an ADDR record for every round. We use the highest ADDR.ADDRNUM for ADDR.ADDRROST to
locate the most current address information.
AV, CL
STADDR1
STADDR2
CITY
STATE
ZIPCODE
We collect two fields for Street Address. Only the first street address field is required.
AV, CL
PHONAREA
PHONEXCH
PHONLOCL
Primary Phone number.
ADDR.PHONAREA = 999 indicates that person does not have primary phone. We do not probe for
Second Phone number if ADDR.PHONEAREA = 999 or RF.
AV, CL
PHONAR2
PHONEX2
PHONLO2
Secondary Phone number.
ADDR.PHONAR2 = 999 indicates that person does not have second phone.
AV, CL
ADDRFNAM
ADDRMINI
ADDRLNAM
First Name, Middle initial, Last Name.
AV, CL
RELASHIP
RELSHPOS
Relationship to SP
Middle Initial is only collected for SP.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM5 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
HLPR
PLAN
PLRO
Section
collected
HF
Important fields
RECORD DELETE
FLAG?
FK?
HLPRROST
Part of Key. Person number. Matches person's ROST.ROSTNUM.
HF
HLPRMOST
HLPRMOST = 1 flags person as person who helps the most.
HF
HLPRUSGO
HLPRUSGO = 1 flags person as person who goes with the SP the most.
HIS/HI
PLANNUM
HIS/HI
PLANHIDE
DELETE FLAG
Is part of key. Plan number.
NOT USED.
HIS/HI
PLANDFLG
DELETE FLAG
Flags PLAN has been deleted.
HIS/HI
MHMODFLG
DELETE FLAG
Flags MHMO has been deleted.
HIS/HI
LOSEPLFG
DELETE FLAG
HIS/HI
PLNAME
HIS/HI
PRVHMO
HIS/HI
PLMIPNUM
HIS/HI
PRVBUS
HIS/HI
PLROPLAN
Flagged by data editing when PLAN used to be valid, but has been replaced by something else. PLAN
should not be displayed in PLAN roster or as Source of Payment.
Name of Health Insurance plan
MEDICARE, MEDICAID, and TRICARE are automatically set for these plan types.
Only stores the first time we collect whether or not private plan is an HMO. Should reference current round
PLRO.PPRVHMO when checking HMO status.
Only stores the first time we collect ROST.ROSTNUM of main insured person. Should reference current
round PLRO.MIPNUM when checking MIP.
Only stores the first time we collect name of busines for MIP. Should reference current rond
PLRO.PPRVBUS when checking MIP business.
Part of Key. Matches PLAN.PLANNUM for plan.
HIS/HI
COVTIME
COVNOW
COVTIME stores whether or not the SP was covered the whole time since the previous round. COVNOW
stores whether or not the SP is covered now, at the time of the interview.
FK
COVTIME = 1/WholeTime or COVNOW = 1/Yes indicates that the Medicare, Tricare, Public or Private plan
is "current" at the time of the interview.
There can only be 1 Medicaid plan, whether or not plan is "current".
There can only be 1 Tricare plan, whether or not plan is "current".
There can be multiple Public and Private plans, either "current" or "not current".
HIS/HI
COVANYTM
COVCURNT
COVANYTIM = /Yes indicates that the SP had the MHMO anytime during the current round, however, this
does not indicate the the plan is "current'.
COVCURNT = 1/Yes indicates that the MHMO is "current".
There can be multiple MHMO plans in a single round.
Only 1 MHMO can be "current". COVCURNT is set "in the background" in HIS/HI based on other
responses.
HIS/HI
MCAIDHMO
HIS/HI
PPRVHMO
HIS/HI
MIPNUM
MCAIDHMO = 1/Yes indicates that the Medicaid plan is an HMO in the current round.
PPRVHMO = 1/Yes indicates that the private plan is an HMO in the current round.
FK
ROST.ROSTNUM of main insured person in current round.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM6 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
DMEM
Section
collected
Important fields
HIS/HI
PPRVBUS
DM
DMEMNUM
LOSEDMFG
DMRO
PROV
DM
DMNAMEX
DM
DMRODMEM
RECORD DELETE
FLAG?
FK?
Name of business for MIP in the current round.
Part of key. Discount membership plan number.
DELETE FLAG
Flagged by data editing when DMEM used to be valid, but has been replaced by something else. DMEM
should not be displayed in DM roster or as Source of Payment.
Name of DM plan. Cheshire stored this name under DMEM.DMNAME, however, we needed to lengthen
the field. The new field name in WVS is DMEM.DMNAMEX.
Part of Key. Matches DMEM.DMEMNUM for DM plan.
Global Utilization
PROVNUM
Part of Key. Provider number.
Global utilization
PROVNAME
Name of Provider
Global Utilization
PROVSPEC
Provider Specialty.
Collected in the following utilization sections:
HHS/HH
Global utilization
PROVTYPE
Provider Type
Collected in the following utilization sections:
HHS/HH
HH
SUBPROV
Name of HH provider who belongs to Provider Organization. In HH, when we probe for a Home Health
provider, we ask if the provider works for an organization. If yes, we collect and store the name of the
organization on PROV and then store the 1st provider name as PROV.SUBPROV on the 2nd PROV
record. The 1st PROV record is deleted if it was a new provider.
Globa utilization
VAPLACE
VAPLACE is asked about providers in utilizations sections.
VAPLACE = 1/Yes indicates that the provider is associated with VA.
VAPLACE is only asked if the SP served in the Armed forces (HOME.SPAFEVER = 1 or
HOME.SPNGEVER = 1) and SP received health care services through VA (HRND.VACOVER = 1/Yes)
and VAPLACE has not been asked for provider.
Once VAPLACE has been asked for a provider, it is not asked again.
Globa utilization
HMOASSOC
HMOASSOC is asked about providers in utilization sections.
HMOASSOC = 1/Yes indicates that the provider is associated with the HMO. HMOASSOC is only asked if
the SP has an HMO anytime during the current round and HMOASSOC has not been asked for provider.
Once HMOASSOC has been asked for a provider, it is not asked again. If HMOASSOC = 2/No, DK or RF
and SP has an HMO anytime during the current round, we ask EVNT.HMOREFER for each event reported
for provider.
COND
Global utilization
ROSTNUMR
FK
ROST.ROSTNUM - NO LONGER USED?
PROVNUMR
FK
ROST.ROSTNUM - NO LONGER USED?
CONDNUM
Part of Key. Condition number.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM7 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
EVNT
Section
collected
Important fields
RECORD DELETE
FLAG?
FK?
Globa utilization
CONDTION
Name of Condition
Global Utilization
EVNTNUM
Global Utilization
EVNTDFLG
Global Utilization
EVNTRNDC
Round # event is reported.
Global Utilization
EVNTTYPE
STEVTYPE
Each EVNT record is identified by an event type. Event type is set in the background depending on which
utilization section the event is collected.
Part of Key. Event number.
DELETE FLAG
Flags EVNT record has been deleted.
EVNT.EVNTTYPE:
DU, ER, IP, OP, IU, HF, HP, MP, OM, PM, SD, SL
EVNT.STEVTYPE is used to properly display/collect the event type in the Statement Event Rosters and
matches EVNT.EVNTTYPE. May not be used in WVS.
OM
OMETYPE
STOMTYPE
If EVNT.EVNTTYPE = OM, we collect the type of OME.
EVNT.OMETYPE:
1 Eyeglasses
2 Hearing
3 Orthopedic
4 Diabetic
5 Ambulance
6 Prosthesis
7 Alteration
8 Oxygen
9 Kidney
10 OtherMedicalExpense
EVNT.STOMTYPE is used to properly display/collect the OME type in the Statement OM Rosters. There
is a unique value for each OMETYPE + sub-OMETYPE.
OM
ORTHTYPE
When we collect OM Orthopedic Items, we further probe for a TYPE of Orthopedic item, such as "walker".
OM
OXGNTYPE
When we collect OM Oxygen related items, we further probe for a Oxygen Supplies or Equipment.
OM
KDNYTYPE
OM
OTHRTYPE
When we collect OM Kidney dialysis related items, we further probe for a Kidney Dialysis Supplies or
Equipment.
When we collect OM Other Medical Expense Items, we further probe for a TYPE of Other Medical Expense
item, such as "Ostomy Supplies".
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM8 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Important fields
RECORD DELETE
FLAG?
FK?
OM
ALTRTYPE
Global Utilization
EVNTPROV
Global Utilization
EVBEGMM
EVBEGDD
EVBEGYY
Event Begin date.
DU, ER, OP, MP, and non-rentals collect only the Event Begin Date.
IP stays, IU stays and OM Rentals collect the Event Begin and End Date.
We do not collect dates for HH visits or PMs.
Global Utilization
EVENDMM
EVENDDD
EVENDYY
Event End date.
DU, ER, OP, MP, and non-rentals collect only the Event Begin Date.
IP stays, IU stays and OM Rentals collect the Event Begin and End Date.
We do not collect dates for HH visits or PMs.
DU, OP, MP
VISTTYPE
RVTIMES
EVNT.VISTTYPE Flags whether event is a Single Visit or Repeat Visit.
Only collected for EVNT.EVNTTYPE = DU, OP, MP events.
EVNT.VISTTYPE = 1/SingleVisit indicates that event is a single visit. EVNT.EVBEGMM/DD/YY are all
filled.
EVNT.VISTTYPE = 2/RepeatVisit indicates that event is a repeat visit. Repeat Visit EVNT.EVBEGDD
should be empty. Note: We may store EVBEGDD = DK in Pilot 2.
EVNT.RVTIMES stores the number of visits.
EVNT.IPSTATUS flags whether or not the SP has been discharged from an IP stay.
OM
IPSTATUS
EV95FLG
OMSTATUS
OM
RENTPROB
OM Rentals.
Certain OM items may be reported as a rental:
Orthopedic items: Crutches, Walker, Wheelchair, Other
Oxygen Equipment
Kidney Dialysis Equipment
Other medical Expense items:
IP
When we collect OM Alterations, we further probe for a TYPE of Alteration, such as "Tub Rails".
FK
PROV.PROVNUM for Provider linked to visit.
OM Alteration status. When collecting alterations in OM, if the alteration is still in progress, we set
OMSTATUS=1/AlterationNotComplete. We do not collect an event date until the Alteration is complete,
OMSTATUS = 2/AlterationComplete.
RENTPROB indicates whether or not the OM is a rental or purchase.
RENTPROB = 2/Rent indicates that the OM is a Rental.
RENTPROB = 1/Buy, DK, and RF indicates that the OM is a purchase.
We collect the Event Begin date for both rentals and purchases.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM9 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Important fields
RECORD DELETE
FLAG?
FK?
RENTSTIL
RENTRECR
RENTENDR
RENTSTILL indicates whether or not the OM is still being rented.
If RENTSTIL = 1/Yes, the OM is still being rented and we do not collect the rental end date. While an OM
item is still be rented, we will continue to probe for COST data in the COST series. In addition, we set
RENTRECR = the current round, indicating the OM was still being rented in the current round.
If RENTSTIL = 2/No, DK or RF, the OM is no longer being rented and we collect the rental end date. In
addition, we set RENTENDR = current round, indicating that the rental ended in the current round. If
RENTSTIL = DK or RF, we set the event end date = DK or RF. Otherwise, we collect the rental end date.
RENT2BUY
RBUYCOST
RENT2BUY indicates whether or not completed rental was a Rent-To-Buy OM.
When a Rental is complete, we ask whether or not the OM item was purchased through a Rent-To-Buy
option. We do not ask this question if the SP is deceased.
RENT2BUY = 2/PurchasedRentToBuy indicates that the Rental was a Rent-To-Buy OM item.
In addition, we will set RBUYCOST = 1/StillCostCollect in OM section so that the OM gets asked about in
the PS section.
The PS section is designed to ask the respondent if there is COST information to report for Rent-To-Buy
OM items in the current round.
If Yes, we will ask about the OM item in the NS section if not already linked to a Statement entered in ST.
In PS, the SP can report no
longer expecting any expenses or payments related to OM item.
At that time, RBUYCOST is updated to prevent OM item from ever being asked about again in PS or NS.
OM
OMATHMO
OM purchased/rented through HMO. Only asked if SP covered by a managed care plan anytime during
the current round.
PMS/PM
PMEDNAME
Global Utilization
EVNTPROV
Name of Medicine
HH
HEROEVNT
Part of Key. Matches EVNT.EVNTNUM for event.
HERORND
Part of Key. Round HH provider provided care.
FK
PROV.PROVNUM for Provider linked to visit.
EVOS
HEAL
HERO
HHS
HERODFLG
DELETE FLAG
In HHS, the SP can report a HH provider event entered in error in the previous round. If HH event entered
in error, we updated HERO.HERODFLG =1/Yes on HERO where HERO.HERORND = previous round.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
10 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
HH
Important fields
RECORD DELETE
FLAG?
HHPLACE
HHPLACOS
FK?
If HH provider works for an oranization, we probe for Type of Organization.
If HHPLACE= 9/LocalGovernment or 10/Church, we not ask Provider related questions such as VAPLACE
and HMOASSOC.
HH
OTHMEALS
If HHPLACE = 2/MealProgram, we probe whether or not the SP received services in the current round. If
not, OTHMEALS = 2/No, DK, RF, we do not collect additional HH details. This HH provider does not
qualify as a HH event in the current round. Therefore, the existance of a current round HERO does not
indicate that the SP had a current round HH provider visit.
HH
HHFTYPE
HHFTYPOS
In HH, we probe for HH professionals (EVNT.EVNTTYPE = HP) and HH Friends or relatives
(EVNT.EVNTTYPE = HF). If HH provider reported as a HH Frienid or relative, we ask HHFTYPE.
If HHFTYPE = 1/Friend or 2/Relative, we not ask Provider related questions such as VAPLACE and
HMOASSOC.
SURG
PMRO
Global utilization
SURGEVNT
Part of Key. Matches EVNT.EVNTNUM for event.
Global utilization
SURGPROV
Name of surgery.
PMS/PM or OM
PMROEVNT
Part of Key. Matches EVNT.EVNTNUM for event.
PMRORND
XMED
XCON
COST
Part of Key. Round PM or OM purchases reported.
PMS
PMRODFLG
DELETE FLAG
PMS/PM or OM
PMROTYPE
In PMS, the SP can drop a PM purchases from previous round. If PM is dropped in PMS, we update
previous round PMRO.PMRODFLG = 1/Yes.
Set to PM or OM.
PMS/PM
PMSATHMO
PM purchased as part of HMO. Only asked if SP had an HMO anytime during the current round.
PMS/PM
PMSATVA
PM purchased through VA. Only asked if the SP served in the Armed forces (HOME.SPAFEVER = 1 or
HOME.SPNGEVER = 1) and SP received health care services through VA (HRND.VACOVER = 1/Yes).
PMS/PM or OM
GETNUM
Number of PM or OM purchases.
XMEDEVNT
Part of Key. Matches EVNT.EVNTNUM for event.
PMs are linked to Dr. visits using XMED. XMEDEVNT is set to the Dr. visit EVNT.EVNTNUM being asked
about.
XMEDEVT2
Part of Key. Matches EVNT.EVNTNUM for event.
PMs are linked to Dr. visits using XMED. XMEDEVT2 is set to the PM EVNT.EVNTNUM linked to the Dr.
visit.
XCONEVNT
Part of Key. Matches EVNT.EVNTNUM for event.
Conditions are linked to Dr. Visits using XCON. XCONEVNT is set to the Dr. visit EVNT.EVNTNUM being
asked about.
XCONCOND
Part of Key. Matches EVNT.EVNTNUM for event. Conditions are linked to Dr. Visits using XCON.
XCONCOND is set to the COND.CONDNUM linked to Dr. visit.
COSTNUM
Charge Bundle COST number.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
11 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Important fields
RECORD DELETE
FLAG?
FK?
COSTTYPE
Flags where COST record is created.
STATTYPE
If COST created in ST section, we probe for "type of statement". STATTYPE flags whether or not the
charge bundle is a Medicare statement, Insurance statement, Tricare statement or a combination of these.
MCARTYPE
MCARTYPE is set to the type of Medicare stateument.
If Statement is a Medicare statement, we further probe for the type of Medicare statement. The type of
statement directs the route to the appropriate question to collect charge related data directly from the
statement.
TOTALAMT
When we collect TOTAL CHARGE/COPAYMENT in COST series, we store the initial response on
CORO.TOTALCHG and we then copy this response to COST.TOTALAMT. COST.TOTALAMT will be set
to the most recent value collected for TOTAL CHARGE/COPAYMENT.
AREMAING
Calculated Amount Remaining.
COSTPROV
FK
PROV.PROVNUM for Provider associated with COST charge bundle.
ORIGNSEV
FK
EVNT.EVNTNUM for original EVNT in No Statement Questionnaire that caused COST to be generated
EXCPSFLG
EXCPSFLG = 2 flags that a charge bundle should no longer be asked about in CPS.
NOCHGNUM
FK
# of OM/PM purchases (PMRO.GETNUM) covered by charge bundle. This value is first collected on
XCEV.NUMLINKS and then is copied to COST.NOCHGNUM.
COST.COSTNUM for other COST in bundle. No longer used.
BUNDMNUM
COSA
COSACOST
CORO
COROCOST
Part of Key. Matches COST.COSTNUM for charge bundle. COSA stores MSN claim control numbers if
ST statement is an MSN.
Part of Key. Matches COST.COSTNUM for charge bundle.
CORORND
Part of Key. Round charges collected.
COROTYPE
Flags where CORO was created, in ST, NS or CPS.
EXMCMAIL
EXMCMAIL = 1/Yes flags that the SP is expecting to receive a statement for an event.
If during the first round an event is reported, if there is not a statement associated with the event, we will
probe for charge information in the NS section. At this time, the respondent can indicate that they expect
to receive a statement and we do not continue to ask additional cost questions.
TOTALTYP
In NS, we either ask for the TOTAL CHARGE or the COPAYMENT for a specific event, depending on if SP
has a managed care plan. TOTALTYP affects the routing in the COST series .
TOTALTYP = 1 flags that TOTAL CHARGE was asked.
TOTALTYP = 2 flags that COPAYMENT was asked.
TOTALCHG
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
12 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
Important fields
RECORD DELETE
FLAG?
FK?
CPSREASN
PAYM
At the beginning of CPS, we review all previous round charge bundles and we assign a "reason" for why
we will ask about the charge bundle in CPS. The routing in CPS is primarily based on CPSREASN.
PAYMCOST
PAYMDFLG
XCEV
Part of Key. Matches COST.COSTNUM for charge bundle.
DELETE FLAG
Flag PAYM has been deleted and is no longer valid.
PAYMPLAN
FK
PLAN.PLANNUM for SOP Payment
PAYMOSOP
FK
OSOP.OSOPNUM for SOP Payment
PAYMDMEM
FK
DMEM.DMEMNUM for SOP Payment
XCEVCOST
Part of Key. Matches COST.COSTNUM for charge bundle.
XCEVEVNT
DELLINK
REIM
Part of Key. Matches EVNT.EVNTNUM for event linked to charge bundle.
DELETE FLAG
RVLINKS
XCEV.DELLINK = 1/Yes flags that event was flagged as no longer part of charge bundle in the field. This
XCEV record will be deleted at the home office.
# of visits (EVNT.RVTIMES) covered by charge bundle.
NUMLINKS
# of OM/PM purchases (PMRO.GETNUM) covered by charge bundle
REIMNUM
Part of Key. Sequential number. Reimbursement number. Reimbursements are not linked to charge
bundles.
PLAN.PLANNUM for SOP reimbursement
REIMPLAN
FK
REIMOSOP
FK
OSOP.OSOPNUM for SOP reimbursement
REIMDMEM
FK
DMEM.DMEMNUM for SOP reimbursement
TSOPNUM
TSOP
OSOP
HRND
Part of Key. Sequential number. During each interview we reload the temporary TSOP table with all
possible Sources of Payments (HI plans, DM's, OSOP's, etc). Each time we load TSOP, each unique
SOP will have a unique sequential number on TSOP.
TSOPTYPE
Flags the type of SOP (SP, PLAN, DM, OSOP, etc.)
TSOPTEXT
Stores name of SOP (SP, plan name, DM name, OSOP name, etc)
TSOPPLAN
FK
PLAN.PLANNUM for SOP
TSOPDMEM
FK
DMEM.DMEMNUM for SOP
TSOPOSOP
FK
OSOP.OSOPNUM for SOP
OSOPNUM
Part of Key. Other Source of Payment (OSOP) number.
LOSEOSFG
DELETE FLAG
OSOPHIDE
DELETE FLAG
Flagged by data editing when OSOP used to be valid, but has been replaced by something else. OSOP
should not be displayed as Source of Payment.
NOT USED.
OSOPTEXT
Name of Other Source of Payment.
Global
HRNDRND
Part of Key. HRND round #.
Global
HRNDRESP
Part of Key. Always set to "01" for community interview.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
13 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
HI
Important fields
RECORD DELETE
FLAG?
FK?
MTFCOVER
Did SP receive Health care from MTF? This question is asked only if SP reported being in the armed
forces (HOME.SPAFEVER = 1 or HOME.SPNGEVER = 1) or SP had a TRICARE plan in the current or
previous round.
If SP responds MTFCOVER = 1/Yes, this response if copied forward each round.
Else it is continued to be asked in HI between TRICARE and Public Plans.
HI
VACOVER
Did SP receive Health care from VA? This question is asked only if SP reported being in the armed forces
(HOME.SPAFEVER = 1 or HOME.SPNGEVER = 1).
If SP responds VACOVER = 1/Yes, this response if copied forward each round.
Else it is continued to be asked in HI between TRICARE and Public Plans.
If VACOVER = 1/Yes (regardless if it is asked in the current round or copied to the current round HRND
record from the previous round record), we ask PROV.VAPLACE in utilization sections.
IN
SPMARSTA
SP's marital status. Is collected in IN when SP is in Supplemental Sample and is updated each FALL
round.
Most recent HRND.SPMARSTA that is not empty is used to check edits when marital status is updated in
the FALL round in IN section.
CL
VSTADDR1
VSTADDR2
VCITY
VSTATE
VZIPCODE
VPHONARE
VPHONEXC
VPHONLOCL
VPHONAR2
VPHONEX2
VPHONLO2
CL
CONTNUM1
FK
CL
CONTNUM2
FK
ROST.ROSTNUM for Contact 2
CL
PHONROST
FK
ROST.ROSTNUM for name next interview phone number under
CL
FPROXNUM
FK
ROST.ROSTNUM for Future Proxy
HHPOWN
FK
ROST.ROSTNUM for person who is head of household.
ENS
(old EN)
SP's vacation home address and phone number.
ROST.ROSTNUM for Contact 1
HEST
IADL
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
14 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Database Critical fields
Structure
Section
collected
ADLS
Important fields
RECORD DELETE
FLAG?
FK?
MOSTADLS
FK
ROST.ROSTNUM of person who helps the most
EOMBREAD
FK
ROST.ROSTNUM of person who reads statements/bills most
WHOPANUM
FK
ROST.ROSTNUM of person who does medicare paperwork
BNPWROST
FK
ROST.ROSTNUM of person who does medicare paperwork
PROV.PROVNUM
HOUS
KNOW
PDRX
PACT
INFO
INVB
ONLN
BKNO
BNED
PFPR
MKIQ
DMRX
MADD
ACCS
INCO
USFACNUM
FK
USDOCNUM
FK
PROV.PROVNUM
USHLPRGO
FK
ROST.ROSTNUM
ACEREVNT
FK
EVNT.EVNTNUM
ACOPEVNT
FK
EVNT.EVNTNUM
ACMPEVNT
FK
EVNT.EVNTNUM
HOMEOWNR
FK
ROST.ROSTNUM OF HOUSE OWNER. STILL USED?
ARNGROST
FK
ROST.ROSTNUM for person who made home care arrangements
SPRVROST
FK
ROST.ROSTNUM for person who is home care supervisor
PRIMHPER
FK
HPER.HPERNUM for primary home care person
HPEREVNT
FK
EVNT.EVNTNUM for HH Event
NEWS
HCAR
HPER
SURV
IRQS
TRNS
HPERPROV
FK
PROV.PROVNUM for HH Provider
SROSTNUM
FK
ROST.ROSTNUM for respondent.
Interviewer Remarks RHELPNUM
FK
ROST.ROSTNUM for person who helped respondent (?)
FK
Remaining portion of key for record updated.
Global
Global
TRNSRKEY
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
15 of 15
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
BASE
Summary of when
Record created
Round Type
Roster
1 record per SP
ALL
n/a
1 record per round
ALL
n/a
Primary
section used Description
GLOBAL
BASE stores basic information about the SP, including SP's CMS loaded DOB, Gender.
A BASE record is generated for each SP as they are added to the study.
MRND
Home Office only MRND stores round-specific management information after a round is completed in the field.
The MRND record is not sent to the field.
Stores a single disposition that summarizes community and all facility interviews in single round.
MRES
1 record per
community and
facility interview per
round
ALL
n/a
GLOBAL
MRES stores Round-and respondent-specific management information, including SP's status, reference dates,
interview type, Proxy information. The SP's interview type and reference dates are set at the Home Office prior to
the case being fielded based on previous round information.
Respondent = 01 reserved for community interview. Can have only 1 community interview in a round.
Respondent = 02..99 reserved for facility interviews. Can have multiple facility interviews in a single round. Once a
Respondent # is assigned to a specific facility for the SP, the Respondent # is then reserved for this facility for this
SP each round the SP resides in this facility. If the SP is discharged and then returns to the facility in a later round,
we will use the same Respondent #.
RCON
1 record per
community and
facility interview per
round
ALL
n/a
Home Office only RCON stores round-specific receipt control information.
The RCON record is not sent to the field.
Used by receipt shop to document case has been completed in the field and to record information sent in to the
home office by the interviewer.
HOME
1 record per SP
ALL
n/a
GLOBAL
HOME stores non-round-specific interview information about SP, including Race, Military status, mailing address.
Typically, data stored on HOME is collected in the first round the SP has a community interview in the study
(MRES.INTTYPE = 2 or 3) and is referenced or updated in later rounds.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM1 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
ROST
Summary of when
Record created
1 record per person
reported
Round Type
Roster
ALL
Person Roster
Primary
section used Description
GLOBAL
ROST stores a list of all persons reported during interviews and includes non-round specific information such as
person's name, relationship to SP, date of birth, and gender.
ROST.ROSTNUM = 01 is reserved for the SP.
The records created on ROST are displayed in the Person Roster. Each time a new person is reported, a ROST
record is created. ROST records are created for SP, Proxy's, Household members, Contacts, Future Proxy,
Helpers, and others.
Throughout the instrument, the interviewer may have opportunities to update information about a person. All
updates to a person's name, relationship, gender or date of birth will be updated on ROST. In addition, the
updates may also be stored on ENUM if the person lives in the Household and/or ADDR if the person is a Proxy,
Future Proxy or Contact. Because ENUM and ADDR records are round specific records, a history of updates
entered for each person can be found on these tables.
A ROST record must exist for all ENUM, ADDR and HLPR records created.
ENUM
1 record per person
living in the SP's
household per round,
or no longer living
with the SP.
ALL
Person Roster
ENS
ENUM stores information regarding who lived in the Household with the SP in a specific round. Information such
as name, relationship, gender, date of birth, Age and job status are stored on ENUM.
Each round, we probe for persons who live in the household with the SP. If a person is reported as living in the
household with the SP, a current round ENUM record will be created that is linked to the person's ROST record.
In addition, if a person lived in the household with the SP in the previous round, an ENUM record is automatically
created for this person in the current round. We then probe in ENS whether or not this person is still in the
household. If the person is no longer in the household, the reason is stored on the current round ENUM.
Therefore, just the existance of a current round ENUM record does not determine whether or not a person lived in
the household with the SP in the current round.
Updates to the person's information on ENUM is also updated on the person's ROST record.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM2 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
ADDR
Summary of when
Record created
1 record per address
collected/updated
per person
Round Type
Roster
ALL
n/a
Primary
section used Description
IN, AV, CL
ADDR stores round specific address, primary and secondary phone numbers, for SP, Proxy, Contacts, and the
Future Proxy.
WVS will always create ONE new ADDR record in Introduction for the SP each round. All updates to the SP's
address, phone numbers or name during a round will be written to the new ADDR record. (NOTE: Cheshire
created a new ADDR record ONLY when SP's name and/or address was updated).
WVS will always create ONE new ADDR record for the Proxy in Introduction each round a person is Proxy. All
updates to the Proxy's address, phone numbers, name or relationship to SP during a round will be written to the
new ADDR record. (NOTE: Cheshire created a new ADDR record ONLY when Proxy's name and/or address was
updated).
In addition, each time a Contact person or a new Future proxy is reported, a current round ADDR record is created
that is linked to the person's ROST record.
The ADDR record stores the person's address and phone numbers. In addition, ADDR also stores the person's
name and relationship to SP. Updates to the person's name and relationship to the SP are also updated on the
person's ROST record.
HLPR
1 record per person
per round who
helped SP.
FALL
Person Roster
HF
HLPR stores round-specific information about persons who assist the SP with ADLs/IADLs/provider visits.
In the fall round, we collect information regarding the SP's health status and usual source of care. Each time a
person is reported who helps the SP, a current round HLPR record is created that is linked to the person's ROST
record. HLPR stores details regarding how the person helped the SP in that round.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM3 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
PLAN
Summary of when
Record created
1 record per health
insurance plan
reported
Round Type
Roster
ALL
Plan Roster
Primary
section used Description
HIS/HI
PLAN stores a list of all Health Insurance plans reported and includes non-round specific plan information such as
the name of the plan. Only one PLAN is created for each unique plan name reported.
The records created on PLAN are displayed in the Plan Roster. Each time a new plan is reported, a PLAN record
is created. The SP may then report stopping and restarting this plan anytime during the study. We collect the
information about the following types of Plans:
Medicare, Plan.PlanType = 01
PLAN.PLANNUM = 01 is reserved for Medicare and is created at the Home Office. We do not probe for Medicare
in HI. Each round, the preloaded Medicare plan is automatically set to "current" on the current round PLRO.
Medicare HMO, Plan.Plantype = 05
A Medicare HMO (MHMO) may be loaded by CMS prior to the SP's first round interview which is verified during the
SP's interview. Additional MHMOs may be reported per round. Multiple MHMO plans may be reported each round,
however, only 1 MHMO may be "current" in a single round. We do not collect Plan start and stop dates for MHMO
plans.
Medicaid, Plan.PlanType = 02.
Only 1 PLAN for Medicaid is created on PLAN. The Plan name is automatically set to "MEDICAID". Only 1
Medicaid plan may be reported per round. We collect Plan start and stop dates for Medicaid.
Tricare, Plan.PlanType = 06
Only 1 PLAN for Tricare is created on PLAN. The Plan name is automatically set to "TRICARE". Only 1 Tricare
plan may be reported per round. We collect Plan start and stop dates for Tricare.
Public Plans, Plan.PlanType = 03
Multiple Public plans may be reported per round. Multiple Public plans may be "current" in a single round. We
collect Plan start and stop dates for Public Plans.
Private Plans, Plan.PlanType = 04
Multiple Private plans may be reported per round. Multiple Private plans may be "current" in a single round. We
collect Plan start and stop dates for Public Plans.
For the following Plan Types, we probe if plan is a Managed Care Plan (HMO):
MHMO - do not probe. Automatically defined as an HMO.
Medicaid
Private Plans
A PLAN record must exist for each PLRO created.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM4 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
PLRO
Summary of when
Record created
1 record per health
insurance plan
reported per round
SP was covered by
plan
Round Type
Roster
ALL
Primary
section used Description
HIS/HI
PLRO stores round-specific Health insurance plan information, including Plan start and stop dates, whether or not
plan is "current" at the time of the current round interview, plan benefits and name of main insured person.
Each time the SP reports being covered by a health insurance plan anytime during the round, a current round
PLRO record is created linked to the PLAN record. We then probe to determine if the plan is "current". Additional
Plan details will be asked based on whether or not the plan is new or restarted, whether or not the plan is current,
whether or not it is a fall round, and whether or not the SP is alive and not institutionalized, institutionalized, or
deceased.
If a new Health Insurance plan is reported in Health Insurance Summary, a new PLAN record is created and the
Plan round number is set to the current round. However, a previous round PLRO is created that is linked to the
PLAN record. A flag is set on PLAN to flag that the PLAN was created in a summary section.
DMEM
1 record per
Discount
Membership plan
reported
ALL
n/a
DM
DMEM stores non-round-specific discount membership plan information, such as the name of the discount
membership plan.
Each time a new discount membership plan is reported, a DMEM record is created. The SP may then report
stopping and restarting this plan anytime during the study.
A DMEM record must exist for each DMRO created.
DMRO
1 record per
Discount
Membership plan
reported per round
SP was covered by
DM
ALL
n/a
DM
DMEM stores round-specific discount membership information, including plan benefits.
Each time the SP reports being covered by a discount membership plan anytime during the round, a current round
DMRO record is created linked to the DMEM record.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM5 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
PROV
Summary of when
Record created
1 record per Provider
reported
Round Type
Roster
ALL
Provider Roster
Primary
section used Description
GLOBAL
PROV stores list of all Medical Providers reported and includes non-round specific information such as the name of
the provider and whether or not the provider is associated with the SP's HMO.
When probing about medical visits and events in utilization sections, we first probe for the name of the provider.
Each time a new provider is reported, a PROV record is created. The provider is then linked to each Dr. visit
reported on EVNT by EVNT.EVNTPROV.
PROV.PROVNUM = 01 is reserved for Other Medical Expense EVNTs and is linked to all OM EVNTs.
PROV.PROVNUM = 02 is reserved for PM EVNTs and is linked to all PM EVNTs.
PROVNUM 01 and 02 are never displayed in the Provider Roster.
EVNT
1 record per Dr. Visit,
OME, PM, HF/HH
provider.
ALL
Event Begin Date
Roster
Event Begin Date
RV Roster
Prescription
Medicine Roster
Statement Event
Roster
Statement Event
Edit Roster
Statement OM
Edit Roster
GLOBAL
UTILIZATION
SECTIONS
EVNT stores a list of Medical events (i.e. Doctor visits, Hospital stays, PM purchases, Other medical expenses)
and includes round-specific information such as type of event, event date, and event details.
In the utilization sections, we probe for information about all Dr. visits (Dentists, Medical Providers), visits to the
ER, Hospital stays, Institutional stays, outpatient department visits, visits from Home Health Care professionals,
PM purchases and Other Medical Expense purchases.
Each time one of these events occur, an EVNT record is created. There are 3 exceptions:
1) Only one EVNT will be created for each unique Home Health Provider reported. Round specific details for each
Home health visit is stored on HERO linked to EVNT.
2) Only one EVNT will be created for each unique Prescription Medicine name. Round specific details for each
PM, such as # of purchases, is stored on PMRO linked to EVNT.
3) Only one EVNT will be created for each the following Other Medical Expenses: Ostomy Supplies, Incontinence
Supplies, and Bandages. Round specific details for each of these OMEs, such as # of purchases, is stored on
PMRO linked to EVNT.
Depending on the event type, specific event details are asked, such as date of event or number of purchases.
Each EVNT record is linked to a provider record by a foreign key, EVNT.EVNTPROV.
OM EVNTs are always linked to EVNT.EVNTPROV=01.
PM EVNTs are always linked to EVNT.EVNTPROV=02.
An EVNT record must exist when an EVOS, HEAL, HERO, PMRO, XMED, XCEV, XCON record is created.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM6 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
EVOS
Summary of when
Record created
1 record per OS text
per EVNT
Round Type
Roster
ALL
n/a
Primary
section used Description
GLOBAL
UTILIZATION
SECTIONS
EVOS stores round specific other-specify information for medical events.
Event details that allow for Other Specify text response are stored on a new EVOS record linked to EVNT. EVOS
stores the other specify text response and the Item tag where the text was collected.
In WVS, we are collecting these fields on EVNT in the SQL database, however, we will be tranforming the EVNT
fields back to EVOS after the case has been fielded.
HEAL
HERO
1 record per HH/HF
EVNT
ALL
n/a
1 record per HH/HF
EVNT per round
ALL
n/a
Not currently in HEAL stores initial Home health care information for each new Home Health Provider event. Although HEAL is still
WVS
being created in Cheshire, we are no longer storing deliverable information on HEAL. In WVS, we chose not to
create a HEAL record in SQL and will need to create the HEAL record after the case has been fielded.
HHS/HH
HERO stores round-specific home health care provider details.
Each time a Home Health care provider visits the SP, a current round HERO is created linked to the Home Health
care provider EVNT. HERO stores current round event details such as how often the provider visited the SP.
In addition, if the Home Health care provider provided care in the previous round, a current round HERO is
automatically created in the current round. We then probe in HHS whether or not the Provider continued to provide
Home Health care in the current round. Therefore, just an existance of a current round HERO does not determine
whether or not the Home Health provider provided care in the current round.
SURG
1 record per Surgery
reported per EVNT
Max 3 Surgeries.
ALL
n/a
IP, OP, MP
SURG stores the name of each surgery reported for IP, OP, and MP events.
Up to 3 surgeries can be reported per event. Each surgery reported is stored on a new record on SURG linked to
the EVNT record. There will be a maximum of 3 SURG records linked to a single EVNT record. SURG stores the
name of the surgery.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM7 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
PMRO
Summary of when
Record created
1 record per PM
EVNT per round
Round Type
Roster
ALL
n/a
Primary
section used Description
OM, PM
PMRO stores round-specific information related to prescribed medicines filled or purchases of Other Medical
Expense Ostomy Supplies, Incontinence Supplies, or Bandages.
Each time the SP reports having a prescription filled, a current round PMRO record is created linked to the PM
EVNT record. PMRO stores the current round number of PM purchases, PM form, strength, amount.
Each time one of the following OMEs, Ostomy Supplies, Incontinence supplies, or Bandages, is reported, a current
round PMRO record is created and linked to the OM EVNT record. PMRO stores the current round number of OM
purchases.
If a PM or OM is reported in Utilization Summary or Prescription Medicine Summary, a previous round PMRO
record is created that is linked to the PM or OM EVNT record. If the EVNT is added new, the EVNT.EVNTRNDC
will be set to the current round and a flag is set on EVNT to indicate that the EVNT was created in a summary
section.
XMED
1 record per PM
reported per EVNT
ALL
n/a
Utilization
XMED is a linking table that links a non-PM EVNT record to one or more PM EVNT records.
For certain event types added in utilization, we probe whether or not the provider prescribed any medicines.
Because prescription medicines are also stored on EVNT, we use XMED to link the Dr. visit EVNT being asked
about to the PM EVNT. There may be multiple PM EVNTs linked to a single Dr. visit EVNT.
XCON
COND
1 record per
Condition reported
per EVNT
ALL
1 record per Medical
Condition reported
ALL
n/a
Utilization
XCON is a linking table that links an EVNT record to one or more COND records.
For certain event types added in utilization, we probe whether or not the Dr. visit was for a specific condition. Since
Conditions are stored on COND, we use XCON to link the Dr. visit EVNT being asked about to the COND record
for each condition selected. There may be multiple CONDs linked to a single Dr. visit EVNT.
Condition Roster
GLOBAL
UTILIZATION
SECTIONS
COND stores a list of all Medical Conditions reported and includes non-round specific information such as the
name of the condition.
Each time a new condition is reported in utilization, a COND record is created and linked the EVNT being asked
about.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM8 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
COST
Summary of when
Record created
1 record per ST, NS
COST data reported
Round Type
Roster
ALL
Statement Charge
Bundle Roster
Primary
section used Description
ST, PS, NS,
CPS
COST stores a list of Statement and non-Statement charge bundles reported in the Statement and No Statement
sections.
After collecting utilization events, we probe for statements. Each statement reported results in a new COST record
generated that is then linked to the EVNTs listed on the statement.
After collecting Statements, we then probe for charges in the No Statement section for any event that does not
have a statement associated with it. A Charge Bundle COST record is generated for each remaining EVNT record.
Multiple EVNTs may be linked to the same charge bundle COST record created in the No Statement section. The
result is that each EVNT record will be linked to a COST record before completing the interview. The only
exception to this is ongoing Rent-to-Buy events.
A COST record must exsit when COSA, CORO, PAYM, XCEV record is created.
COSA
1 record per MSN
COST reported
ALL
n/a
ST, PS, NS,
CPS
COSA stores the Medicare Summary Notice claim control numbers collected in the Statement section. Because
not all health insurance statements are MSN's and since the MSN claim control numbers are lengthy, we chose to
store the claim numbers on a separate table.
CORO
1 record per COST
per round
ALL
n/a
ST, PS, NS,
CPS
CORO stores round-specific cost information, such as total charges, medicare payments, amount remaining.
Each time a new charge bundle is reported, either a Statement or charges in the No Statement section, a current
round CORO is created linked to the Charge Bundle COST record. Charge bundles are not only asked about in
the current round, but may also be asked about in the COST Payment Summary section for up to rounds that
follow. The purpose of the COST Payment Summary section is to collect charge or payment information that may
have been unavailable in the previous round. This information is stored on the round specific CORO record linked
to the COST record.
PAYM
1 record per SOP
Payment reported
ALL
n/a
ST, PS, NS,
CPS
PAYM stores Charge Bundle payment information.
Each time a Charge Bundle is reported, we probe for sources of payments. For each payment reported, the type of
payer and the amount paid is stored on PAYM and is linked to the Charge bundle COST record. The types of
payers may include the SP/Family, Provider Discount, Medicare, the SP's Health Insurance Plans, the SP's
Discount Membership plans, or an Other type of Source of Payment.
If the Source of Payment is a health insurance plan, discount membership plan or an other type of Source of
Payment, PAYM stores a foreign key that links to the PLAN, DMEM, or OSOP tables.
PAYM stores the discount membership plan number for all DM payers.
XCEV
1 record per EVNT
linked to COST per
charge bundle
ALL
n/a
ST, PS, NS,
CPS
XCEV is a linking table that links a COST record to one or more EVNT records.
Each time a Charge Bundle is reported, the events covered by the charge bundle are linked to the Charge Bundle
COST record. Multiple EVNTs may be linked to a COST record.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM9 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
Summary of when
Record created
Round Type
Roster
Primary
section used Description
REIM
1 record per
reimbursement
reported
ALL
n/a
CPS
TSOP
1 record per possible
SOPs, including
PLANs, DMEMs,
OSOPs, others
ALL
SOP Roster
ST, NS, CPS
REIM stores reimbursement information. Each reimbursement received is stored on a new record on REIM.
TSOP is a temporary table that is used to load all possible Sources of Payments at the Source of Payment roster.
The possible Sources of Payments include the SP/Family, Provider Discount, Medicare, the SP's Health Insurance
Plans, the SP's Discount Membership plans, or an Other type of Source of Payment.
The TSOP table is loaded during the interview. The data is used only during data collection and is not transformed
back to the home office.
OSOP
1 record per Other
Source of Payment
reported
ALL
n/a
ST, NS, CPS
OSOP stores a list of Other Sources of Payments and includes non-round specific information such as the name of
the Source of Payment.
Each time a new Other Source Of Payment is reported, a new OSOP record is created that is linked to the
Payment PAYM record.
Once an Other Source Of Payment is reported, it remains on the Source of Payment Roster and may be selected
for future Charge Bundles.
HRND
1 record per
interview per round
ALL
n/a
GLOBAL
HRND stores miscellaneous round-specific community interview data, including utilization/health insurance/cost
series probes, Medicare and Medicaid card information, marital status, # children, information collected in Closing,
such as SP's vacation home address, Contact 1 and 2 information, Future Proxy information, Next interview phone
number and name.
HEST
1 record per
interview per
SUPPLEMENT
round
FALL
n/a
HF
HEST stores round specific information collected in the Health status and functioning supplemental section (except
ADLs/IADLs).
IADL
1 record per
interview per
SUPPLEMENT
round
FALL
n/a
HF
IADL stores round specific information collected in the Health status and functioning supplemental section related
to IADLs.
ADLS
1 record per
interview per
SUPPLEMENT
round
FALL
n/a
HF
ADLS stores round specific information collected in the Health status and functioning supplemental section related
to ADLS.
HOUS
1 record per
interview per
SUPPLEMENT
round
FALL
n/a
HA
HOUS stores round specific information collected in the Housing Characteristic supplemental section.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
10 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
Summary of when
Record created
Round Type
Roster
Primary
section used Description
KNOW
1 record per
SUPPLEMENT
round
WINTER
n/a
PDRX
1 record per
interview per
SUPPLEMENT
round
WINTER and
SUMMER
n/a
PACT
1 record per
SUPPLEMENT
round.
SUMMER
n/a
PA
INFO
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
NFO stores round specific information collected in the Sources of information about Medicare supplemental
section.
1 record per
Verbatim text string
per SUPPLEMENT
round.
?
n/a
DROPPED
INVB stores Verbatim text collected in Sources of Information about Medicare supplemental section. Each line of
text collected on the Verbatim screen is stored on a new record on INVB. INVB stores the VB text and the item tag
where the text was collected.
ONLN
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
ONLN stores round specific information collected in the Knowledge and opinions about HCFA Online supplemental
section.
BKNO
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
BKNO stores round specific information collected in the Knowledge about Medicare supplemental section.
BNED
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
BNED stores round specific information collected in the Beneficiary Information Needs supplemental section.
PFPR
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
PFPR stores round specific information collected in the Pharmacy Patient Profile supplemental section.
MKIQ
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
MKIQ stores round specific information collected in the Medicare Knowledge
Supplement(combines:BKNO,BNED,KNOW) supplemental section.
DMRX
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
DMRX stores round specific information collected in the Discount Prescription Drug card use supplemental section.
MADD
1 record per
SUPPLEMENT
round.
?
n/a
DROPPED
MADD stores round specific information collected in the Medicare Approved prescription drug card supplemental
section.
INVB
KN
KNOW stores round specific information collected in the Beneficiary Knowledge and Information Needs
supplemental section.
PD - WINTER PDRX stores round specific information collected in the Medicare Part D Drug Benefit supplemental section.
RX - SUMMER
PACT stores round specific information collected in the Patient Activation supplemental section.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
11 of 12
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Version # 07.01.0001
Summary of Database Tables
Structure
Summary of when
Record created
Round Type
Roster
Primary
section used Description
ACCS
1 record per
interview per
SUPPLEMENT
round
FALL
n/a
AC, SC, US
ACCS stores round specific information collected in the Access to Care supplemental section.
INCO
1 record per
interview per
SUPPLEMENT
round
SUMMER
n/a
IA
INCO stores round specific information collected in the Income and Assets supplemental section.
NEWS
1 record per
interview per round
?
n/a
??
NEWS stores round specific information collected for the New Enrollee Sample in R46.
HCAR
NO LONGER USED
?
n/a
NO
HCAR stores a list of Home health care provider survey information collected.
An HCAR record must exist if an HPER record is created.
HPER
NO LONGER USED
?
n/a
SURV
1 record each time
case is
accessed/updated
ALL
n/a
IRQS
1 record per
interview per round
ALL
n/a
TRNS
1 record per update.
Fields that require
TRNS record are
specified by design.
ALL
n/a
NO
HPER stores round specific informaton for Home health care provider survey information collected.
Not currently in SURV stores a history of case access, including date and time stamp and function performed. Each time a case
WVS
is accessed, a SURV record is created.
IRQ
IRQS stores round specific information collected in the Interviewer Remarks questionnaire.
Not currently in TRNS stores a history of field updates made to prior round data. Each time prior round data is updated in the field,
WVS
a TRNS record is created that stores the name of the field updated, the table and Key that was updated, the old
value and the new value. Not all fields updated will have a TRNS record created. This is determined by the
project staff.
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM
12 of 12
Version # 07.01.0001
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Database Table Keys
Structure
BASE
MRND
KEY
KEY FIELD
NAME
Fields that are a subset of KEY FIELD NAME
Sample Person ID (8)
BASEID
BASEID
Round # record
created, not part
of key.
Summary of Data stored
n/a
Basic information from CMS
BASEID (8) + Round # (2)
MRNDID
MRNDBASE
MRNDRND
n/a
Round Specific dispositions
MRES
MRNDID (10) + Respondent # (2)
MRESID
MRESBASE
MRESRND
MRESRESP
(01)
n/a
Interview Specific Interview
Type, reference dates,
respondent information, and
dispositions
RCON
MRNDID (10) + Respondent # (2)
RCONID
RCONBASE
RCONRND
RCONRESP
(01)
n/a
Receipt Control data
BASEID (8)
HOMEID
HOMEBASE
n/a
Non-round specific general
information
HOME
ROST
BASEID (8) + Sequential # (2)
ROSTID
ROSTBASE
ROSTNUM
ENUM
ROSTID (10) + Round # (2)
ENUMID
ENUMBASE
ENUMROST
ENUMRND
ADDR
ROSTID (10) + Address Sequential #
ADDRID
ADDRBASE
ADDRROST
ADDRNUM
HLPR
ROSTID (10) + Round # (2) + Sequential # (2)
HLPRID
HLPRBASE
HLPRROST
HLPRRND
PLAN
ROST.ROSTRNDC
n/a
ADDR.ADDRRNDC
HLPRRESP
(01)
n/a
Address Information
Person's who help the SP
BASEID (8) + Sequential # (2)
PLANID
PLANBASE
PLANNUM
PLANID (10) + Round # (2)
PLROID
PLROBASE
PLROPLAN
BASEID (8) + Sequential # (2)
DMEMID
DMEMBASE
DMEMNUM
DMEMID (10) + Round # (2)
DMROID
DMROBASE
PROV
BASEID (8) + Sequential # (2)
PROVID
PROVBASE
PROVNUM
PROV.PROVRNDC
Providers
EVNT
BASEID (8) + Sequential # (3)
EVNTID
EVNTBASE
EVNTNUM
EVNT.EVNTRNDC
Medical visits and purchases
EVOS
EVNTID (11) + Sequential # (2)
EVOSID
EVOSBASE
EVOSEVNT
EVOS.EVOSRNDC
HEAL
EVNTID (11)
Other Specify Text per
Medical visit/purchase
Home Health visits
PLRO
DMEM
DMRO
HERO EVNTID (11) + Round # (2)
PLAN.PLANRNDC
Persons
Household Information
PLRORND
DMRODMEM DMRORND
EVOSNUM
Health Insurance plans
Round specific Health
Insurance coverage
information
DMEM.PLANRNDC
Discount Membership plans
n/a
Round specific Discount
Membership plan coverage
information
HEALID
HEALBASE
HEALEVNT
HEROID
HEROBASE
HEROEVNT
(HEROHEAL
in
Cheshire)
HERORND
HEAL.HEALRNDC
n/a
SURG
EVNTID (11) + Sequential # (2)
SURGID
SURGBASE
SURGEVNT
SURGNUM
SURG.SURGRNDC
PMRO
EVNTID (11) + Round # (2)
PMROID
PMROBASE
PMROEVNT
PMRORND
n/a
Round specific Home Health
visit information
Surgeries per Medical visit
Number of purchases per
Medical PM or OM purchase
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM 1 of 3
Version # 07.01.0001
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Database Table Keys
Structure
KEY
KEY FIELD
NAME
Fields that are a subset of KEY FIELD NAME
Round # record
created, not part
of key.
Summary of Data stored
XMED
EVNTID (11) OF VISIT + EVNTID (11) OF MEDICINE
XMEDID
XMEDBASE
XMEDEVNT
XMEDBAS2
XMEDEVT2
XMED.XMEDRNDC
XCON
EVNTID (11) + CONDID (10)
XCONID
XCONBASE
XCONBASE
XCONBAS2
XCONCOND
XCON.XCONRNDC
COND
BASEID (8) + Sequential # (2)
CONDID
CONDBASE
CONDNUM
COND.CONDRNDC
Conditions
COST
BASEID (8) +Sequential # (3)
COSTID
COSTBASE
COSTNUM
COST.COSTRNDC
Charge Bundles
COSA
COSTID (11)
COSAID
COSABASE
COSACOST
COSA.COSARNDC
Charge Bundle MSN numbers
CORO
COSTID (11) + Round # (2)
COROID
COROBASE
COROCOST
CORORND
n/a
PAYM
COSTID (11) + Sequential #
PAYMID
PAYMBASE
PAYMCOST
PAYNNUM
PAYM.PAYMRNDC
XCEV
COSTID (11) + EVNTID (8)
XCEVID
XCEVBASE
XCEVCOST
XCEVBAS2
Round specific charge bundle
information
Payment information per
charge bundle
Links charge bundle to
Medical visits and purchases
XCEVEVNT
Links PM purchases to
Medical visits
Links Conditions to Medical
visits
REIM
BASEID (8) + Sequential # (3)
REIMID
REIMBASE
REIMNUM
REIM.REIMRNDC
Reimbursements
TSOP
BASEID (8) + Sequential # (2)
TSOPID
TSOPBASE
TSOPNUM
TSOP.TSOPRNDC
Sources of Payments
OSOP
BASEID (8) + Sequential # (2)
OSOPID
OSOPBASE
OSOPNUM
HRND
BASEID (8) + Round # (2) + Respondent #(2)
HRNDID
HRNDBASE
HRNDRND
HEST
HRNDID (12)
HESTID
HESTBASE
HESTRND
IADL
HRNDID (12)
IADLID
IADLBASE
IADLRND
ADLS
HRNDID (12)
ADLSID
ADLSBASE
ADLSRND
HOUS
HRNDID (12)
HOUSID
HOUSBASE
HOUSRND
KNOW
HRNDID (12)
KNOWID
KNOWBASE
KNOWRND
PDRX
HRNDID (12)
PDRXID
PDRXBASE
PDRXRND
PACT
HRNDID (12)
PACTID
PACTBASE
PACTRND
INFO
HRNDID (12)
INFOID
INFOBASE
INFORND
HRNDRESP
(01)
HESTRESP
(01)
IADLRESP
(01)
ADLSRESP
(01)
HOUSRESP
(01)
KNOWRES
P
(01)
PDRXRESP
(01)
PACTRESP
(01)
INFORESP
(01)
OSOP.OSOPRNDC
Other Source of Payments
n/a
n/a
Interview Specific probes,
general information
Health Status information
n/a
Health Status information
n/a
Health Status information
n/a
Housing information
n/a
Beneficiary Knowledge
information
n/a
Medicare Prescription Drug
Plan
Patient Activation
n/a
n/a
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM 2 of 3
Version # 07.01.0001
MCBS WVS R55 GENERAL SPECIFICATIONS FOR BAISE/WVS
Database Table Keys
Structure
INVB
KEY
KEY FIELD
NAME
Fields that are a subset of KEY FIELD NAME
INVBNUM
Summary of Data stored
INFOID (12) + Sequential #
INVBID
INVBBASE
INVBRND
ONLN
HRNDID (12)
ONLNID
ONLNBASE
ONLNRND
BKNO
HRNDID (12)
BKNOID
BKNOBASE
BKNORND
BNED
HRNDID (12)
BNEDID
BNEDBASE
BNEDRND
PFPR
HRNDID (12)
PFPRID
PFPRBASE
PFPRRND
MKIQ
HRNDID (12)
MKIQID
MKIQBASE
MKIQRND
DMRX
HRNDID (12)
DMRXID
DMRXBASE
DMRXRND
MADD
HRNDID (12)
MADDID
MADDBASE
MADDRND
ACCS
BASEID (8) + Round # (2)
ACCSID
ACCSBASE
ACCSRND
n/a
Access to Care
INCO
BASEID (8) + Round # (2)
INCOID
INCOBASE
INCORND
n/a
Income and Assets
NEWS
BASEID (8) + Round # (2)
NEWSID
NEWSBASE
NEWSRND
n/a
HCAR
BASEID (8) + Round # (2)
HCARID
HCARBASE
HCARRND
n/a
HCARID (10) + Sequential # (3)
HPERID
HPERBASE
HPERRND
HPERNUM
SURV
BASEID (8) + Date + Time
SURVID
SURVBASE
SURVDATE
SURVTIME
IRQS
BASEID (8) + Round # (2) + Respondent # (2)
IRQSID
IRQSBASE
IRQSRND
IRQSRESP
(01)
TRNS
BASEID (8) + Sequential # (5)
TRNSID
TRNSBASE
TRANSNUM
HPER
INVBRESP
(01)
ONLNRESP
(01)
BKNORESP
(01)
BNEDRESP
(01)
PFPRRESP
(01)
MKIQRESP
(01)
DMRXRESP
(01)
MADDRESP
(01)
Round # record
created, not part
of key.
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Interview management
informaiton
n/a
TRNS.TRNSRNDC
Interviewer comments
Record of changes made to
database
Z:\share\IMG\OMB\2010\Final\attachment 04\English\General Specifications\General Specifications Database_07.01.0001.xls 03/30/2010 4:33 PM 3 of 3
| File Type | application/pdf |
| Author | Lisa Sweeney |
| File Modified | 2010-03-30 |
| File Created | 2010-03-30 |