There are several auto-enter options that can enter data from either the previously visited record (that can be hard to control sometimes) or a related record (which can be set up with a self-join).
I think, however, your system would work better for you if your medication list for a given patient record was recorded in a set of related records displayed in a portal. With this approach, you'd pull up a patient record (or create a new record for this patient's visit) and a PatientID field would link the current record to their current medication list table and you can then modify the records in this portal to update their current medication list.
Thanks for the reply!
I think I understand what you're talking about with the portal solution, but would modifying the records in the portal maintain the history of the medications? If a patient was taking medication X in June, but the dosage was increased in July, would there be a single record for that patient taking that medication, or two different ones with dates?
As described above, it would not. I'd still use the portal approach as many other database tasks become easier when you have one related record for each listed medication.
By using a script and a slightly different relationship, you can duplicate the medication records so that the portal displays records copied from the previous office visit for that patient.
That now gives you two options. You can define a "self join" based on PatientID with a looked up value setting to copy the medications from a field into the new office visit record or you can use a script to duplicate the medication records, but update them with an "officeVisitID" number from the new office visit record so that the duplicated records automatically appear in your portal on the office visit layout.