Checkbox Form

[StephenG57]

I am in the process of designing a medications list database for my office, one where we can record a patient's list of medications they are taking during their check in process. One key to this design will be ease of use.

I know that I could use an inventory-like setup, whereby I would have a table labeled med_chart (similar to a purchase order set up). Utlizing a med_join file portal on the med_chart table, it would pull information from a continually updated medications table of products used. I have presented this, and although it works, the nurses find it very cumbersome.

Instead of a portal where they use individual entries to generate their chart of meds for a particular patient, they would like to have me design a one page form in checkbox format listing all the medications. They would simply check the boxes of the medications to generate their chart record. I could do that with a simple flat file, but we're talking 100's of medications in the one table, of which would have to include in Case/Replace calculations making this too cumbersome...for them and for me.

I guess what I'm asking, is using a checkbox form to generate join file entries possible? Are there any articles or examples where this is done that I could study? Or should I just simply stick with the portal format and hope this data entry will not greatly impede their check in process?

I'm stuck...thanks in advance for your response.

[StephenG57]

I am in the process of designing a medications list database for my office, one where we can record a patient's list of medications they are taking during their check in process. One key to this design will be ease of use.

I know that I could use an inventory-like setup, whereby I would have a table labeled med_chart (similar to a purchase order set up). Utlizing a med_join file portal on the med_chart table, it would pull information from a continually updated medications table of products used. I have presented this, and although it works, the nurses find it very cumbersome.

Instead of a portal where they use individual entries to generate their chart of meds for a particular patient, they would like to have me design a one page form in checkbox format listing all the medications. They would simply check the boxes of the medications to generate their chart record. I could do that with a simple flat file, but we're talking 100's of medications in the one table, of which would have to include in Case/Replace calculations making this too cumbersome...for them and for me.

I guess what I'm asking, is using a checkbox form to generate join file entries possible? Are there any articles or examples where this is done that I could study? Or should I just simply stick with the portal format and hope this data entry will not greatly impede their check in process?

I'm stuck...thanks in advance for your response.

[StephenG57]

I am in the process of designing a medications list database for my office, one where we can record a patient's list of medications they are taking during their check in process. One key to this design will be ease of use.

I know that I could use an inventory-like setup, whereby I would have a table labeled med_chart (similar to a purchase order set up). Utlizing a med_join file portal on the med_chart table, it would pull information from a continually updated medications table of products used. I have presented this, and although it works, the nurses find it very cumbersome.

Instead of a portal where they use individual entries to generate their chart of meds for a particular patient, they would like to have me design a one page form in checkbox format listing all the medications. They would simply check the boxes of the medications to generate their chart record. I could do that with a simple flat file, but we're talking 100's of medications in the one table, of which would have to include in Case/Replace calculations making this too cumbersome...for them and for me.

I guess what I'm asking, is using a checkbox form to generate join file entries possible? Are there any articles or examples where this is done that I could study? Or should I just simply stick with the portal format and hope this data entry will not greatly impede their check in process?

I'm stuck...thanks in advance for your response.

[Fenton]

How about this idea for a "chart" table. Use a series of side-by-side portals, with specified rows (1-30, 31-60, etc.). That could show quite a lot (depending on screen size and width of the names). Use a scripted button to move the clicked data to the patient's medications log table. That provides much the same functionality of multiple entries at once.

It would look sort of like the checkboxes (but I like the idea of the transfer happening at once, rather than waiting and requiring another click to move all the choices). You could also actually set a checkbox, in the chart file, if they really want to see one; not needed though.

The portals could also be for different "groups," with different groups on a few different layouts. That would cut down the number of items on one screen.

Another idea would be to do the above, but rather than presenting all the possible meds, first present a screen with the Patient's previous meds, if these are return visits. This would a small number of records, easy to check off. Then, if necessary, flip to a layout with ALL the meds, to add new ones.

The only trick would be to get that list of previous meds into a field so that the 1st portal was filtered. This could be fairly easily done using the ValueListItems (Get(FileName), "PatientMeds"), with a relationship filtered with the patient ID. This could be done from anywhere that has the PatientID.

Or use a filtered portal by letter for additions. These methods can be combined (it's more work, but not a whole lot). Let them make multiple entries for likely medications (a small list), and choose from a filtered list for new ones (a large list). If they type the first few letters of the medication, it should knock the list down to a reasonable size for the portal. You only need 3-5 letters for 1000 entries.

You could also group the medications, so that they can make one choice, for the "group", then a 2nd portal pops into place (same little window) with the meds of that group.

If you combine the 2 filter methods, with a group choice, then a letter filter, you could easily do thousands. Yes, it's more typing that clicking a checkbox. But if it's done right it would be better than looking down a checkbox of several hundreds of entries.

[Fenton]

How about this idea for a "chart" table. Use a series of side-by-side portals, with specified rows (1-30, 31-60, etc.). That could show quite a lot (depending on screen size and width of the names). Use a scripted button to move the clicked data to the patient's medications log table. That provides much the same functionality of multiple entries at once.

It would look sort of like the checkboxes (but I like the idea of the transfer happening at once, rather than waiting and requiring another click to move all the choices). You could also actually set a checkbox, in the chart file, if they really want to see one; not needed though.

The portals could also be for different "groups," with different groups on a few different layouts. That would cut down the number of items on one screen.

Another idea would be to do the above, but rather than presenting all the possible meds, first present a screen with the Patient's previous meds, if these are return visits. This would a small number of records, easy to check off. Then, if necessary, flip to a layout with ALL the meds, to add new ones.

The only trick would be to get that list of previous meds into a field so that the 1st portal was filtered. This could be fairly easily done using the ValueListItems (Get(FileName), "PatientMeds"), with a relationship filtered with the patient ID. This could be done from anywhere that has the PatientID.

Or use a filtered portal by letter for additions. These methods can be combined (it's more work, but not a whole lot). Let them make multiple entries for likely medications (a small list), and choose from a filtered list for new ones (a large list). If they type the first few letters of the medication, it should knock the list down to a reasonable size for the portal. You only need 3-5 letters for 1000 entries.

You could also group the medications, so that they can make one choice, for the "group", then a 2nd portal pops into place (same little window) with the meds of that group.

If you combine the 2 filter methods, with a group choice, then a letter filter, you could easily do thousands. Yes, it's more typing that clicking a checkbox. But if it's done right it would be better than looking down a checkbox of several hundreds of entries.

[Fenton]

How about this idea for a "chart" table. Use a series of side-by-side portals, with specified rows (1-30, 31-60, etc.). That could show quite a lot (depending on screen size and width of the names). Use a scripted button to move the clicked data to the patient's medications log table. That provides much the same functionality of multiple entries at once.

It would look sort of like the checkboxes (but I like the idea of the transfer happening at once, rather than waiting and requiring another click to move all the choices). You could also actually set a checkbox, in the chart file, if they really want to see one; not needed though.

The portals could also be for different "groups," with different groups on a few different layouts. That would cut down the number of items on one screen.

Another idea would be to do the above, but rather than presenting all the possible meds, first present a screen with the Patient's previous meds, if these are return visits. This would a small number of records, easy to check off. Then, if necessary, flip to a layout with ALL the meds, to add new ones.

The only trick would be to get that list of previous meds into a field so that the 1st portal was filtered. This could be fairly easily done using the ValueListItems (Get(FileName), "PatientMeds"), with a relationship filtered with the patient ID. This could be done from anywhere that has the PatientID.

Or use a filtered portal by letter for additions. These methods can be combined (it's more work, but not a whole lot). Let them make multiple entries for likely medications (a small list), and choose from a filtered list for new ones (a large list). If they type the first few letters of the medication, it should knock the list down to a reasonable size for the portal. You only need 3-5 letters for 1000 entries.

You could also group the medications, so that they can make one choice, for the "group", then a 2nd portal pops into place (same little window) with the meds of that group.

If you combine the 2 filter methods, with a group choice, then a letter filter, you could easily do thousands. Yes, it's more typing that clicking a checkbox. But if it's done right it would be better than looking down a checkbox of several hundreds of entries.

[StephenG57]

Thank you very much for your response Fenton. Right now, the powers at be are fairly adamant in using the checkbox format, but I think your side by side portal idea will work the best when I have time to provide them with a working model similar in appearance to their current comfort level.

As such, for the interum, I have constructed medications list, chart_record and link them using a meds_join file. Very similar to the inventory program setup. To overcome the checkbox issue, I have used a script button at the bottom of the page which "posts" the results of the checkbox choices into the meds_join file. It utilizes ValueCount and MiddleValues to translate the arrayed entries into individual join_file records. Again, more complexity than I like, but it works and they seem happy with the result. More importantly, it will still allow me to harvest data from the meds_join file for reports.

Again, you have helped me immensely with pointing out the many different approaches to "skinning this cat", and I'm sure as i learn more about 7, I will utilize many of your suggestions. Thanks!

[StephenG57]

Thank you very much for your response Fenton. Right now, the powers at be are fairly adamant in using the checkbox format, but I think your side by side portal idea will work the best when I have time to provide them with a working model similar in appearance to their current comfort level.

As such, for the interum, I have constructed medications list, chart_record and link them using a meds_join file. Very similar to the inventory program setup. To overcome the checkbox issue, I have used a script button at the bottom of the page which "posts" the results of the checkbox choices into the meds_join file. It utilizes ValueCount and MiddleValues to translate the arrayed entries into individual join_file records. Again, more complexity than I like, but it works and they seem happy with the result. More importantly, it will still allow me to harvest data from the meds_join file for reports.

Again, you have helped me immensely with pointing out the many different approaches to "skinning this cat", and I'm sure as i learn more about 7, I will utilize many of your suggestions. Thanks!

[StephenG57]

Thank you very much for your response Fenton. Right now, the powers at be are fairly adamant in using the checkbox format, but I think your side by side portal idea will work the best when I have time to provide them with a working model similar in appearance to their current comfort level.

As such, for the interum, I have constructed medications list, chart_record and link them using a meds_join file. Very similar to the inventory program setup. To overcome the checkbox issue, I have used a script button at the bottom of the page which "posts" the results of the checkbox choices into the meds_join file. It utilizes ValueCount and MiddleValues to translate the arrayed entries into individual join_file records. Again, more complexity than I like, but it works and they seem happy with the result. More importantly, it will still allow me to harvest data from the meds_join file for reports.

Again, you have helped me immensely with pointing out the many different approaches to "skinning this cat", and I'm sure as i learn more about 7, I will utilize many of your suggestions. Thanks!