{smcl}
{* 10jul2009}{...}
{* DIR: VHA Acute Myocardial Infarctions, FY2004+}{...}
{cmd:help docs acs}
{hline}

{title:Details for {cmd:acs} documentation}

{pstd}This help file includes information for accessing {cmd:acs} documentation through the {cmd:docs} command. If it doesn't seem to make sense, see {help docs}.{p_end}
{hline}

{title:Description}

{pstd}This dataset is based on the EPRP ACS data abstraction. It combines EPRP data from fiscal year 2004 onward with selected bits from PTF and the VA vital status file.
It includes about 96% of AMIs treated in a VA medical center, as well as many cases of unstable angina through fy2009.

{title:Datasets}

{pstd}{cmd:acs}

{pstd}There is a single dataset, which should never need to be explicitly specified.

{title:Additional Keys}

{pstd}{cmd:eprp}

{pstd}You can look up {cmd:acs} variables by the {cmd:eprp} variables that influenced them. Skips are included, i.e.,
specifying an {cmd:eprp} field will bring up an {cmd:acs} field even if the effect is only indirect.

{pstd}Example: {cmd:. docs eprp:closecg}

{title:Metadata}

{pstd}{cmd:Label Frequency Description}

{phang}{ul:{cmd:Label}}: This is simply the variable label from the {cmd:ccfcs} data.

{phang}{ul:{cmd:Frequency}}: This is a one-way tabulation of the field, including all missing values, and either all data values or the single value "not missing", depending on the nature of the data.

{phang}{ul:{cmd:Description}}: If the field came from EPRP data, all the relevant abstraction instructions for all the fields that contribued data will be included - BUT, only for one recent period; the instructions change over time.
There will also be two links back to the EPRP documentation: one that shows how the instructions have changed over time, and one that shows how the skip conditions have changed over time.
To delve into those details, one would need to examine the EPRP docs directly (with {cmd:docs @eprp}).

{phang}Example: {cmd:. docs , l f d}

{title:Missing Values}

{p2colset 0 5 7 2}
{p2col: {cmd:.w}}Missing because of {hi:when} the data was abstracted. Over time (i.e., quarters of the fiscal year) the data collected for EPRP changes, with fields added and dropped.
If data required for a particular field was not being collected at the time a record was abstracted, the field will be missing with {hi:.w}.
The distinct abstraction periods are coded by the variable {hi:docid}.

{p}{cmd:.i} {cmd:.t} {cmd:.a} {cmd:.b} EPRP data collection varies significantly depending on:

{pstd}o- whether or not the ACS occurred when the pt was already in a VA hospital{p_end}
{p 7}Coded by {hi:acs_inpt}, and giving a missing value of {hi:.i}

{pstd}o- whether or not the pt was transferred from a community hospital{p_end}
{p 7}Coded by {hi:acs_trc}, and giving a missing value of {hi:.t}

{pstd}o- whether or not neither is true (ie, the patient was admitted to a VAMC with ACS){p_end}
{p 7}Coded by {hi:acs_admit}, and giving a missing value of {hi:.a}

{pstd}o- in some periods, whether or not both are true{p_end}
{p 7}Coded by {hi:acs_both}, and giving a missing value of {hi:.b}{p_end}

{p2col: {cmd:.n}}Missing because there was {hi:no} evidence of AMI, or no treatment for AMI. The specific criteria vary by quarter & by data field. Overall, this is coded in the two variables {hi:noami1} and {hi:noami2}

{p2col: {cmd:.d}}Missing by {hi:discharge} type. Some data was not collected if patients died, or were discharged to hospice or another hospital. This is coded by {hi:dctype}.

{p2col: {cmd:.e}}Missing because of {hi:early} discharge of one type or another. Coded by {hi:dc1day}

{p2col: {cmd:.x}}Missing because this admission was essentially {cmd:excluded} from EPRP data collection. The two possible reasons (as of fy2010) are that the patient was on palliative care, or participating in clinical trials.
The reason is coded in {hi:excluded}.

{p2col: {cmd:.h}}{hi:Hole} in the data. This value can occur when data from a single original field is recoded into two or more fields.
For example, data on a procedure might have originated in a single field with three potential values: {bf:yes}/{bf:no}/{bf:pt refused}.
If the data are then recoded into two fields, {hi:px}: {bf:yes}/{bf:no}, and {hi:contraindications}: {bf:yes}/{bf:no}, here is how the data would translate:

{ralign 15:{hi:orig}}{col 20}{bf:yes}{col 30}{bf:no}{col 40}{bf:pt refused}

{ralign 15:{hi:px}}{col 20}{bf:yes}{col 30}{bf:no}{col 40}{bf:no}

{ralign 15:{hi:contra}}{col 20}{bf:no}/{bf:.p}{col 30}{bf:.h}{col 40}{bf:yes}

{p 7 7 2}If the original field coding the procedure were {bf:yes}, the contraindication might be {bf:no} or {bf:.p} depending on the specific abstraction instructions.

{p2col: {cmd:.m}}{hi:Missing} from patient record. Abstractor says info is not there.

{p2col: {cmd:.p}}{hi:Pre}-condition/{hi:pre}requisite not met/not relevant. For example, if a drug is not prescribed, the type of drug will be missing with {cmd:.p};
if a procedure is not performed, the procedure date will be missing with {cmd:.p}.
Still, many instances in the data are much less sensible than this; if the abstraction instructions specified skipping a field for some reason, and the reason is not covered by the other missing values, it will be {cmd:.p}.

{p2col: {cmd:.}}Unexplained missing