Greetings all, I am working on a Rails application that primarily deals with data collection and reporting. The application is to be used in a clinical environment, of which includes an obstetrical/maternity unit and various supportive and wellness programs. The application exists greatly to support various studies, short term, ongoing, and future. With this in mind, I want to anticipate the need to add studies onto the application''s core data tracking functionality -as easily as possible, and in a way that integrates well into an existing workflow. So far I have defined a set of models that are for collecting and reporting on the domain''s core data (a foundation of information if you will, on which a study should sit, or at least sit next to). This data includes objects such as mothers, children, pregnancies, births, and so on. Now, studies (new models) will most often relate to one of these core models [1], but more specifically to objects that have a certain state. Take for instance a study on C-Sections (a method of delivering a baby). A C-Section study would relate to objects of the core `birth'' model, because a birth defines an attribute called `delivery_method'' that explains how a baby was delivered. When a birth''s delivery_method is set to some value representing a C-Section, the C-Section study should be available to that birth object. In terms of the application''s functionality, when a data entry person has entered in a birth record where the delivery_method happens to be by C-Section, they are notified of an available study that relates to this particular birth. In fact, you should be able to ask a core object for a list of studies that relate to it''s particular state. Thus, what I am looking for is a modular system of adding new studies to my application, in a way which allows core objects to become aware of them as they are added (without having to modify any core models). I am interested in doing this in the most ruby/rails centric way possible. I thought rail''s ActiveRecord acts_as methodology could be useful. For instance one could make an acts_as_study plugin/module and use it somehow like: class CSection < ActiveRecord::Base acts_as_study :on => :births, :with => "delivery_method == C-Section" end I guess the acts_as_study call would somehow register the CSection model as an available study to birth objects with the given attribute state. (Use some other class/collection to do this? Perhaps one could extend ActiveRecord::Base to add some kind of registration capability). This way I could anticipate some collection of studies for each core object, and code it into the application''s functionality (controllers/views), allowing for study models to be easily integrated later on by simply adding a new model acting as a study. This could also be facilitated with generators, etc. I am interested in any thoughts about how to make this modular system, and if the acts_as methodology makes sense to use -and if so where I can learn about creating my own acts_as module. I am thinking also that this relationship of core models and study models can be generalized for use with other applications that need to manage these kinds of relationships (particularly the collect and report type). I hope I explained that well enough. Anyway, thanks for taking a look, Brad [1] - Studies relating to one core model is what is expected most often, however this is not the only possibility. Studies that relate to no core model may mean something was missing from the core structure, or that the study itself is not exactly in the application''s core domain. Studies that relate to more than one core model could indicate bad design in the core structure, but may also make sense in a number of cases.