I've been working on the data model for a healthcare mobile app that will collect the user's symptoms and will book an appointment with a doctor if requested by the user.

I was thinking the app would list the available symptoms and the patient could choose from them, and then the system would estimate some illness based on the chosen symptoms and perhaps this Illness record could be a foreign key in the Diagnosis table. Then, when booking an appointment, there would be a foreign key to this Diagnosis record in the Appointments table. Later, this Diagnosis tuple could be updated by the doctor during the appointment. The problem with this approach is that this way in the Diagnosis table we are only storing some estimated illness instead of the actual symptoms of the patient that were present when booking the appointment.

I'm having trouble figuring out the model for the Diagnosis table, and also what to include in the Appointments table (besides doctor name, appointment date etc. which are not relevant to the question) regarding the diagnosis provided by the app.

What do you suggest should constitute the Diagnosis table? Should I store the symptoms of the patient instead of the estimated illness and refer to this in the Appointments table rather than some illness which later might get overwritten by a doctor anyway? If so, this would mean that we don't know how many attributes (symptoms) one record of the Diagnosis table could have, but they would all be just foreign keys to the Symptoms table.

Also, do you think I can model and do this in a relational database or should I be thinking of a NoSQL database? I'm only listing the tables that I think are relevant to the question:

symptoms:            illnesses:                                 diagnosis:         appointments:

id    name           id    name               FK_symptoms?      id    ?    ?       id    FK_patient_name     FK_diagnosis
1     fever          1     pneumonia                            1                  1
2     chills         2     allergic rhinitis                    2                  2
3     sore throat    3     asthma                               ...                ...
4     headache       ...

What other approach would you suggest?

  • 1
    What does "I've been working on the data model for a healthcare mobile app " mean? Is it a real app in use or in development, or something hypothetical that you're working on as part of some studies? Are you working with a team?
    – bdsl
    Commented May 12, 2021 at 21:15
  • Not sure if inspired or an independent idea, but this site seems to do the diagnosis part and might be worth studying as a related example: symptomate.com
    – liori
    Commented May 12, 2021 at 21:29

2 Answers 2


Frame challenge: unless this is a toy project not intended for a real-life application I suggest you study existing models that represent healthcare data instead of reinventing the wheel. There are more complexities in this area than you might think. One example would be the HL7 FHIR model, which, incidentally, has multiple open-source server implementations that are ready to be used.

This intro on Coursera might be helpful too.


Quite the challenge there. I'll lay out a few things you should definitely keep in mind, and then some suggestions for your data model.

  • PII/PHI: All medical information tends to have a lot of personally identifiable information and protected health information, this comes under a ton of regulation in most places in the world, particularly HIPAA in the US.

  • Medical diagnosis/expert systems: In the US, this is potentially going to come under regulation by the FDA as "Software as a Medical Device", especially if diagnosis is involved. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications It's when you move from the patient recording their own information for sharing with a doctor over to suggesting diagnosis or storing doctor diagnosis (which is usually a signed medical record) where regulation starts to really kick in.

  • Medical records: the doctor is typically going to be entering their findings in their own EMR system, possibly in plain text or through dictation, and it might end up being coded later by another staff member. And maintenance of these records is the responsibility of the physician, so while as a patient you may have access to the records, you are not normally the custodian of them. As mentioned in the previous answer, I would definitely look at FHIR to see what your app could potentially get access to on behalf of the patient by using the FHIR standard to connect to a system which holds their medical records, and then potentially link the records there to the personal records your app maintains - by using encounter information in the FHIR schema.

  • Coding systems: While there are standard coding systems that are used for reporting for input, diagnosis, billing, insurance, analysis and reporting to registries, there isn't one system that accommodates all specialties and use cases adequately. You have probably heard of ICD, SNOMED, DSM which all have standard codes in a variety of revisions, and even these can be inadequate in some specialties. So when you pull in FHIR data, you will be getting all that kind of data. On the patient side, there are some codes for symptoms in ICD and SNOMED, and SNOMED coding is frequently used for input because it is very detailed. But identifying the right code to describe a patient's symptom might be very difficult - a doctor is not going to just accept your codings as accurate and put them directly into their system.

  • Medical data is messy: doctors can record both that there is impression of a history of some syndrome or incident or that the syndrome is present at the encounter. So in the medical record you can have both recordings of history of syndromes and a history of recordings of syndromes, if you understand what I'm getting at. Some diagnosis might cover a number of symptoms, they might overlap - there is not a guarantee that everything is linked up to everything else.

Regarding whether to use a relational store or a non-relational store, because medical data can be structured in a very schemaless way, you might be better off with a mix of document-store techniques for a lot of the clinical data (symptoms, diagnosis, images, medications, treatments) but relational store techniques for the non-clinical data (appointments, schedules). Clinical data is often not easily amenable to large-scale analysis that the relational model affords without conforming the data to a model or very complex harvesting of the semi-structured data and either way this really requires a lot of clinical expertise which is probably outside the scope here.

I would recommend more fully fleshing out some use cases of what a patient wants to capture and share with a physician then revisiting the model:

On what basis are the symptoms meant to be attached to an appointment? All the symptoms seen since the last appointment? All the symptoms in a particular location in progress over all time, regardless of appointments (like long term blood pressure history)? What other events might need to be correlated, like medications and changes to medications?

All these point to the appointments and diagnosis really being independent of the symptoms in the model, but perhaps with some correlation which is a little more dynamic.

So for symptoms, obviously time, duration, frequency, severity is an important aspect which should be recorded with symptoms and useful to have a record over time. Again, some of this may be codable in an existing scheme. And you will get into pre- and post- coordinated coding where there might be one code that represents the syndrome and frequency combination together, or there might be two independent codes for syndrome and frequency and both get provided in the finding.

And then an appointment or set of appointments and referrals all may be loosely linked to some or all of those symptoms, but not necessarily.

I know that doctors do often LOVE patients to have specific quantifiable information about symptoms they bring with them in an easy to use form (for example Kardia - https://store.alivecor.com/products/kardiamobile), so I don't want to discourage you, but it is a very large problem space with a lot of moving parts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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