Possible scheme to implement in MongoDB

What you want to do is find some "things that go together" and group them into one document in Mongo. It's a trade-off, and there is no one correct answer.

Let's say you're storing forms that a patient fills out in a doctor's office.

Option 1: You could store everything in a single document. This is a good choice if the system doesn't need to "tie in" with the patient's other records. For example, you're running a short survey on patient habits, but aren't putting it in their medical records and aren't tracking specific patients over time. This Option is the 'simplest' for document stores like Mongo. It is also the highest-performance, since only one disk read is needed per form. But if a patient fills out many forms, you'll be wasting a lot of disk storing the patient name on each copy of the form.

Option 2: You could "break off" the data about a patient into a 'Patients' collection, and only store patient_id on the form object. This is the simplest in relational, but in Mongo it requires you to write extra code. (Your ORM may help here). The good news is that it's easier to avoid duplicate patient records. But now it's slower (since it must do a client-side database join every time you look at a form).

Option 3: You could combine Option 1 and Option 2: Store patients in the patient collection, but ALSO keep their data in the form. That way, for example, you could say "the Patient's address is X, but at the time they filled out the form, their address was Y". The downside is that it requires more storage.

Option 4: If there are a limited number of values (say a clinic that only sees 10 patients), you could "hard-code" these in your program (i.e. load them from a config file, or load them from a Patient collection at startup). That way, you're not doing a client-side DB join when displaying a patient.

Repeat the above thought exercise for each "thing" in your form (Doctor, Medication, Patient Address, etc.) If you find you want a LOT of collections, you're probably better off with a relational database. If you find it easy to keep the number of collections low, then Mongo might be a good choice.

It's recomended to embed related entities which you expect to be in low number, keep in mind that mongodb objects can't occupy more than 16mb.

I think that mongo is the perfect tool for flexible data "schemes"

http://docs.mongodb.org/manual/core/data-modeling/

However if you dont feel confortable with no-relational DBs and your application is very important I would not do experiments