Closed timcknowles closed 6 years ago
above issues aside (which I've created as a separate issue in the longer-term roadmap https://github.com/openhealthcare/opal-ideas/issues/46)
this can be closed via https://github.com/Epidurio/opal-epidur.io/pull/32
I agree, this should be expanded out from a single field with a CHOICES list to a number of separate Boolean fields. This will be a small change to the model.
Longer term, and with more relevance to the overall design of Opal ( @fredkingham @davidmiller ) I could see a point where it could get difficult to add a new column to the DB for each and every new complication we thought of...
In GP systems they don't go into such fine detail with their data structures, relying instead on the use of a Terminology (Read/SNOMED etc).
Can we find a way to allow a field to have free text, a foreign key OR a coded data item from a terminology? If we could have a number of coded data items in a single field, this would give unbelievable flexibility in the UI as medicine changes over time. It's one for opal-ideas really, but I thought it was worth mentioning in context here.