0

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.

  • 2
    "I picked mongodb, because I'm afraid the requisites for this database will be changing from time to time" - I disagree with this. I belive in schema-first approach to developing business applications. If business changes, business pays. – NoChance Oct 11 '14 at 20:42
2

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.

0

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
-1

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.

  • It has both, but it has more write than read data. I basically want to add different "encounters" to each patient. From time to time (each 2 or 3 months), we need to know how many diabetic patients we have, or how many patients with less than certain value of blood pressure do we have. Is that what you were asking or I misunderstood the question? – Pablo Olmos de Aguilera C. Jul 13 '14 at 0:41
  • I don't have a better answer - you might want to consider migrating this to dba.stackexchange.com – Kevin Jul 13 '14 at 0:48
  • Well, I think I'll consider using a relational database since data itself it's very easy to enter, and most of it are "true/false", or just plain integers. I don't think we are going to be dealing with enormous amounts of data anyway, and consistency it's not a life-death matter. Right now, people here are counting big papers with the data written by hand, which is cumbersome. That's the problem we are trying to solve. – Pablo Olmos de Aguilera C. Jul 13 '14 at 1:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.