Is this requirement feasible with django

[Kalpa Welivitigoda]

Hi,

I want to develop a web based laboratory test reporting system. It
basically involves storing the records of different tests for
different patient and get a print out of the reports. There are around
100 tests with different fields.

The flow would be that the user enters a patient id and the tests for
that person appears, then he selects one test and a input form appears
to enter test results. This continues for the other tests as well and
finally a print out is issued and a pdf of the report is generated on
request.

Since there are around 100 tests (with different fields), do I need to
write separate models and views (to view the data input form) for each
and every one of them or can it be made simpler at least generating
views (because views are generated from some of the fields in the
model) ?

--
Best Regards,

Kalpa Pathum Welivitigoda
http://about.me/callkalpa

[Bill Freeman]

The sticky word above is "simpler". Beyond a hand written model
per test, possibilities include programmaticly generating the models,
having all possible fields in one model and hiding the ones which are
inappropriate for a particular test (see the fields and exclude options
for the ModelForm Meta class, IIRC), to having a single test model plus
a set of test_field models, having a ForeignKey relation to the test
model, and created pointing to a test instance according to the test
type. (This last may involve your view creating a form-like object.)

So, what do you consider simple.

Someone else may have better suggestions.

Bill

[Python_Junkie]

I hope my answer points you in the right direction.

I would create 2 (generic) tables one  that is called something like test_definition, since you have a wide variety of tests.

And then create a table called test results.

The forms that the user fills in would be created dynamically through the view by extracting the appropriate row information from the test_definition table.

Reports results can be created by joining the test_definition table with the test_results table.

The test_results table would be appear to be genric, ie column_A, Column_B. but pull the required metadata from the test_definition field.

Hence you would only need 2 models

[akaariai]

There are a couple of ways to go forward I know of.

The simplest pattern is just to have all the tests as Models. This is
likely a road of a lot of pain to maintain, but it is definitely worth
trying if this works for you. Creating new Python models isn't that
complicated, and with South migrations are somewhat easy to do, too.

Another somewhat common pattern is to use EAV (entity-attribute-value)
style tables. The modeling would be something like:
class Patient:
<patient_info>

class Test:
<test_info>

class PatientTest
FK(patient)
FK(test)

class PatientTestResult
FK(PatientTest)
attr_type
attr_value

So, for each patient - test combo you can store attributes of that
test. It is somewhat common to then model also metadata of what
attributes each test can potentially have, so that you can dynamically
construct the forms and/or create procedures which validate the data.
This can feel like a clever way forward, but my personal experience is
that this is actually going to be a pain to maintain. Another problem
is that most trivial queries easily becomes an unholy mess of joins +
subselects (or you need PIVOT queries, or something else like that).
For example I have a EAV system to maintain where querying pretty
basic information about an employee requires 50+ joins.

Consider carefully before going down the EAV road. Avoid storing any
validation logic in the database.

I would likely try to go with a format where you store the test
results in JSON/XML/HStore(if using PostgreSQL)/some other vendor
specific datatype. If you need to do calculations on the test results,
you can then transform the serialized format to (denormalized)
database tables for the calculations. If this transformation feels
like a lot of work, remember that if you have EAV you will still need
to do this, or write queries you really don't want to be writing. If
you have some common attributes (identifier code, date of test,
location of test, the person who did the test, etc) then model these
into SQL tables. Just the result fields should go into the serialized
format.

This is one area where there really aren't any right answers. You need
to prototype what works for your use case.

- Anssi