Conversation
|
|
||
| class SymptomSubType(models.Model): | ||
| symptom_id = models.ForeignKey(SymptomType, on_delete=models.CASCADE) | ||
| name = models.CharField(null=False, blank=False) |
There was a problem hiding this comment.
This 2-step hierarchy should be enough to store the symptom name, and also an optional secondary categorisation, e.g. in the case of Skin changes, this would be "How has the skin changed?"
MatMoore
force-pushed
the
dtoss-10724-symptoms
branch
from
d0f38bb to
4048375
Compare
| investigated = models.BooleanField() | ||
|
|
||
| # Onset information | ||
| when_started = models.CharField(blank=True, null=False) |
There was a problem hiding this comment.
There is some overlap here with how we model participant reported mammograms. In both cases we support a more specific date entry and a free text option.
I considered maybe extracting a specific model for this, like ParticipantReportedDate, but am thinking it's better to leave this until we have a couple more usages of this, and wait and see if the patterns evolve.
The two usages are slightly different because reported mammograms collect Year/Month/Day, whereas symptoms collect only Year/Month.
ParticipantReportedMammogram also has a few fields for capturing place in different ways, which also seems potentially reusable, but for symptoms we are not capturing this at the moment, only a boolean "yes this was investigated"
| # Onset information | ||
| when_started = models.CharField(blank=True, null=False) | ||
| year_started = models.IntegerField(null=True, blank=True) | ||
| month_started = models.IntegerField(null=True, blank=True) |
There was a problem hiding this comment.
Alternatively we could use a DateRange for this. But it seems a bit more complex.
| ) | ||
| participant_id = models.ForeignKey(Participant, on_delete=models.PROTECT) | ||
| appointment_id = models.ForeignKey(Appointment, on_delete=models.PROTECT) | ||
| reported_at = models.DateField() |
There was a problem hiding this comment.
this field might be implied by the appointment date, but in the future it could be collected pre-appointment so explicitly setting a date seems like a good idea
MatMoore
force-pushed
the
dtoss-10724-symptoms
branch
from
476a806 to
7c6cb99
Compare
| SymptomSubType, on_delete=models.PROTECT, null=True, blank=True | ||
| ) | ||
| participant = models.ForeignKey(Participant, on_delete=models.PROTECT) | ||
| appointment = models.ForeignKey(Appointment, on_delete=models.PROTECT) |
There was a problem hiding this comment.
I can see why we'd need to associate with appointment, but if that's the case, can we simply infer the participant via the appointment record rather than also storing participant foreign key?
There was a problem hiding this comment.
Yes we can. I've dropped the column.
Only downside is it will require multiple joins if we want to access participant data and symptom data together, e.g. 'appointment__screening_episode__participant`
I also added some methods just to delegate down to the participant so you don't have to do thing.appointment.screening_episode.participant everywhere
| NIPPLE_CHANGE = "nipple-change" | ||
| OTHER = "other" | ||
|
|
||
| name = models.CharField(null=False, blank=False) |
There was a problem hiding this comment.
Can I see an example of what kind of values you see name and id fields storing, for a both a SymptomType and SymptomSubType record?
There was a problem hiding this comment.
The name would just be a human readable version of the ID.
type: skin-change / "Skin change"
subtype: sores-or-cysts / "Sores or cysts"
It's not important that the participant reported the symptom, just that it was captured during/in preparation for the appointment. It's possible the mammographer could also notice symptoms such as lumps during an appointment that the participant hasn't reported. We may later support mammographers recording that, in which case we would use the same model, but perhaps add an extra field to specify the provenance. Features captured as part of image reading will be modelled separately later.
MatMoore
force-pushed
the
dtoss-10724-symptoms
branch
from
8f28047 to
af3f6a8
Compare
MatMoore
force-pushed
the
dtoss-10724-symptoms
branch
from
6abaab3 to
3312a2b
Compare
2 participants
Description
Add some models so we can store participant-reported symptom information in a generic way.
Diagram
(note ParticipantRecordSymptom has been shortened to just Symptom)
Jira link
https://nhsd-jira.digital.nhs.uk/browse/DTOSS-10724
Review notes
I've split up the participants app's
models.pyinto multiple files to make it somewhat easier to work on.Django doesn't exactly encourage this, and arguably we should split up the participants app instead, but I'm not feeling very confident that I could come up with a good split criteria right now, so I'd rather postpone app-level restructuring unless anyone else has a good idea of what it should look like. Maybe we should have another look at the app structure once we reach the point where we have most of the core functionality built out.
I decided not to try and model symptoms and other kinds of medical informations (like implants, treatments, pregnancy and breast feeding) as one generic thing. They're different enough to be hard to model generically, and I expect this would create headaches later down the line. However, symptoms should be modelled in such a way that we can easily extend the specific symptoms we ask about.
There are also some commonalities between this and participant reported mammograms which we have already implemented (see inline comments)
There are no codes associated with the symptoms yet - but I'm envisioning that we will add them to the SystemType model at a later date.