Help with database design with a strict and structured subset of clinical data

Question

I'm developing an application to keep some of the data in chronic patients, the data came from a very strict subset of data, vital signs, exams, ecc.

On a first glance I thought to create a Patient model with has_many encounters, and put every info in a different field like (age, height, weight, ecc), but it will result in a big model. So I wondered about embedding to make it easier to maintain and scale if in a couple of months I need to register a new exam, right now I have been thinking in something like this:

Patient

name: string,
address: string,
phone: integer,
diagnose: string,
etc...

Encounters

patient_id: ObjectID,
age: Integer,
vital_signs: [ { height, weight, bmi, systolic_pressure, diastolic_pressure } ],
exams: [ { creatinine, total cholesterol... } ],
next_encounter: Date

I'm going to still need to access to bmi for example if I want to get how many people in the community is obese (hint: an awful lot), so embedding maybe it's not a very good idea. In any case, all the "analysis" will only be done only monthly (or less).

I picked mongodb, because I'm afraid the requisites for this database will be changing from time to time, so flexibility it's important.

Maybe in this case since data is structured, every document will have the same types of fields, a relational database could be better? I don't think it makes sense using a nosql database in a sql way, right?

PS.- I read this article from mongodb blog, and I'm more confused about if this really it's the best approach.

Answer 1

Maybe in this case since data is structured, every document will have the same types of fields, a relational database could be better?

Most likely.

I don't think it makes sense using a nosql database in a sql way, right?

Nope. To hesitate a guess, people will start asking you questions like:

• What age was bob smith on their third examination?

• When did john doe's weight drop below 90kgs?

• How many examinations have we done on people with high blood pressure?

So, read up on data modelling, look at a few other example schemas and go for it.

Answer 2

Thoughts -

1. Definitely better in an RDBMS.
2. Check for existing standard schemas for medical data. (HL7)
3. Comments on the suggested table structure:-

Patient

name: string,
address: string,
phone: integer,
diagnose: string,
DOB Date (Date of Birth)
etc...

Encounters

patient_id: ObjectID,
Date_of_Examination: Date, 

(With Patient DOB, patient age can be calculated for the Encounter)

vital_signs: [ { height, weight, bmi, systolic_pressure, diastolic_pressure } ],

(possibly better to break this out into two tables: Vital Sign Types, Encounter-Vital Signs in case a new Observation type is added)

exams: [ { creatinine, total cholesterol... } ],

(DEFINITELY break this out into Examination Types, Encounter-Examinations)

next_encounter: Date

Answer 3

What is the use case of the data, reporting or just serve app functionality?

Relational databases are great for structuring data for reporting, but you can develop more rapidly with NoSQL because if it's lack of schema constraints.