I'm working on another module of the hospital rounding app. In our last episode, we got the ECG module working so the providers can add some echo reading data to a patient record while rounding. I am now trying to implement another module for tracking data relevant to gout.
I'll need to be able to enter the uric acid level, date, who recorded the data, and when. These are easy items, been done plenty before by way of a secondary table to contain the records and a ref to tie related records back to the patient record.
The next part is where I "may" need some help. At the moment, i'm talking out loud and spitballing to see if I can come up with something. As always, I would prefer a gentle nudge in the right direct as opposed to being spoon fed an answer.
I'll need the ability to add a series of medications the patient is currently taking, the dosage for each medication, and how long they have been taking that particular medication. If i understand the feature requests, essentially, it'll need to be a series of medications the patient is on as of that entry, but the series itself be considered one record. I am requesting clarification on how the data will be used and how it might change, as the use case scenario should help to better tailor the user experience and hopefully lead to proper data design.
That said, my current thought is, is there a way within appsheet to have a table of sorts with columns for medication, dosage, and date, then a button to add another item/row and fill in the data for that row, preferably while keeping the table view visible? I guess I could use an "add row" button which would take them to a sub-form to enter the data for that row, then take them back to the table view.
I'm overthinking this, i think ๐ค
UPDATE: I may have just answered my own question but for the sake of documenting the thought process, I'm looking at this order capture example and it seems that this may be a good option:
https://www.appsheet.com/templates/An-app-for-managing-customers-products-and-orders?appGuidString=8...
okay, talking about loud again to try to get this completed. I have drawn out some diagrams to help me visualize and i think what i need to do, when compared to the order entry app, is to make tables for
Medications
This table would contain _medicationID, Medication Name, and Medication Category. Essentially a database of products, as compared to the Order Capture app example pasted above.
Medication Details
This table would contain a ref to a _medicationID for the medication, a ref to _patientIdentifier to tie the detail to the patient, and dosage information.
In theory, the Medication Category column would be used in a slice to have, for example, Gout medications able to show up in the Gout section, Diabetes medications to show up in the Diabetes section, and so on, but also have the ability to show a complete Medication List tied to the patient
In theory, Medication List would be a slice, i think, that pulls in medications tied to the patient, but then again, i think the medication list may be dynamically generated by way of ref, if i understand.
@Steve does this look right? I feel like i have spent too long thinking about this and not enough time doing, but i want to do my best to get this right on the first attempt through proper planning and understanding an expected end result. If i can get the table structure proper, i can then craft buttons and actions to do things as needed.
Looks good to my quick reading.
Are you developing with your production app? Or do you have a way to develop that doesn't affect production. "i want to do my best to get this right on the first attempt" concerns me that you don't.
a little bit of both. Dead simple things, i sometimes do "live." Other things that i know may break something, i make a copy of the app to work in, then merge the changes after i'm sure it works. I wasn't ever contacted by the enterprise folks to upgrade our licenses, so the copy and merge method, while a little bit clunky, is working
as for the get it right on the first attempt part, i tend to try to plan as far as i can before doing and make sure things make sense in my head/on paper before i start trying to build. It doesn't always work out, ofcourse, but i suppose its an extension of the carpenter's saying "measure twice, cut once"
User | Count |
---|---|
18 | |
13 | |
8 | |
4 | |
2 |