Here are two different ways to handle merging data into a form to create a paragraph (or more) something like mail-merge.  There is no particular reason to have two, except that the first (notes) was the first way I did it.  It was easy to implement but is a little bit of a pain to use since you have to keep track of the order of the fields (and if they change the form stops working).  I can't think of any reason you would want to install version 1.  It is only included for completeness.  If you do install (i.e., import) version 1 and then install version 2 on top of it, you will have to reset your Newton to see the effects of the installation.  Leverage doesn't handle the imports that overwrite existing database definitions as cleverly as it might.

In both versions there are two databases: notes, and note forms.

Note forms contains the boiler plate for the various notes into which substitutions are made to create the real notes.  It has two fields: form, which is the name by which the note form is identified, and text, which is the actual boiler plate text.

In version 1 the boiler plate looks like:

The patient, ^0 is a ^1 year old ^2 complaining of ...

The ^# tokens are replaced with fields when the actual note is constructed.

In version 2 the boiler plate looks like:

The patient, |name| is a |age| year old |sex| complaining of ...

Here the replacement tokens are identified by surrounding vertical bars and are replaced by name from fields in the other database.  So long as the fields specified exist they will be replaced correctly, regardless of order.

The other database, notes, contains the replacement data and the resulting note, as well as a field that is used to select the appropriate note form to use to create the note.  The replacement occurs when the form is selected (and the field box closed).  I usually fill in the data at the top, select the form (there is only one, named test, in the sample database), and then tap on the note field to open it and look at the resulting note.  A record in this database looks like:

Name:  Bullwinkle J. Moose
Age:  21
Sex:  male
Side:  left
Anatomic Site:  antler
Years:  3
Operation:  radical keratectomy
Form:  test
Note:  The patient, Bullwinkle J. Moose, is a 21 year old male complaining of ...

Some thought needs to be given to the question of how to generalize the procedure so that the substitution data (i.e., Name, Age, etc.) doesn't have to be the same for each note.  That could be done using this technique, but it would require a different database for each collection of data (not perhaps that unreasonable after all).