Hi. I recently asked a question about standardizing a proc genmod model to the total population distribution of a number of covariates (age, sex, status), regardless of variable distributions of these within each individual group.    In the course of @StatDave advising me how to query the coefficient weight by using the "e" option in an lsmeans statement to produce a "coef" output , I discovered that the weights I expected for the population when using the "om" option were not being produced by my model. They were weighting to something but I couldn't figure out what exactly.   After some proc freq testing, I realized the dataset I am using is a summarized data set, where each row has a variable representing the number of outcomes in those that meet that distribution of characteristics (numcount), and a variable representing those at risk for the outcome with those same characteristics (denomcount).    proc genmod data=imputed_data; by _imputation_; CLASS group (ref='A') age (ref='<25') status (ref='Jr') sex (ref='Male'); MODEL numcount = group age status sex /dist=poisson link=log offset=logdenomcount; lsmeans group/ exp diff cl om e; ods output ParameterEstimates=gm_fcs1 estimates=model_est lsmeans=allestimates diffs=relrisk; run; Since my poisson model had an offset for the denomcount (logdenomcount), I hadn't thought that weighting was necessary. However, when I looked at the "coef" output produced by e, I couldn't get the true population weights unless I added a weight=denomcount statement. Once added this produced the coefficient weight I would expect given the distribution of my sample (e.g., male =.8, female=.2, etc.).    I just want to confirm that this is appropriate (necessary) when data is summarized as described. Can someone please confirm?  This is my first time working with both imputed data and summarized data in this type of model so I appreciate your help!     (Below is a snippet of how the dataset is laid out: ) Obs sex age status      group _Imputation_ _TYPE_ _FREQ_ numcount denomcount num denom logdenomcount 1 Male <25 years old Jr A 1 255 26 1 26 1 1 3.25810 2 Male <25 years old Jr B 1 255 13 1 13 1 1 2.56495 3 Male <25 years old Jr C 1 255 250 12 320 1 1 2.56495         ... View more

I am estimating rates and rate ratios of an outcome using proc genmod with a poisson distribution for multiply imputed data. Sample code is below. I do not include the follow on steps (e.g., proc mianalyze, etc.) for brevity.   proc genmod data=imputed_data; by _imputation_; CLASS group (ref='A') age (ref='<25') status (ref='Jr') sex (ref='Male'); MODEL numcount = group age status sex /dist=poisson link=log offset=logdenomcount; lsmeans eth/ exp diff cl om=imputed_data; estimate "A" intercept 1 group 0 0 1 /exp ; estimate "B" intercept 1 group 1 0 0/ exp; estimate "C" intercept 1 group 0 1 0/ exp; ods output ParameterEstimates=gm_fcs1 estimates=model_est lsmeans=allestimates diffs=relrisk; ods select none; run;     For an estimated rate for Group A, I want the model covariates (age, status, sex) to be weighted according to actual covariate distribution of my entire sample due to imbalances across levels of variables  by group. (In other words, what would the rate be for group A (or B or C) if its age, sex, and status distribution were the same as the entire study population?) If I am understanding the documentation correctly, then I want to use the om= or obsmargins option so that the "coefficients (are changed) to be proportional to those found in the OM-data-set" as mentioned here. In other words, I don't want estimates per the LSmeans default, which "estimate the marginal means over a balanced population" as stated here.      Two questions:  1) Is my reason for wanting the "om" option correct? I can elaborate if further clarification is needed. 2) Am I applying the "om" option incorrectly? My estimates are not changing when I add om, om=imputed_data, obsmargins, or obsmargins=imputed_data. I tested rates with both lsmeans and estimates, and rate ratios with ParameterEstimates and diffs and they are each the same, respectively.  Thank you for your feedback!   ... View more