Your database needs a lot of work. I would have tried to fix it but the intent is still not clear. Looking at your report gives more insight into what you want though. Clearly, in the real world, there won't always be two of everything. In the world of relational databases, when you have more than one of something, you have "many" and many means you need a separate table. Something we cal all relate to is a person's dependents. If you are creating an employee application and you want to store information about the employee's dependents, would you add some number of columns to the employee table to hold the names of the dependents? How many columns would you add? Most American families have fewer than 5 children so would you add, 6 columns? How about 7 to be safe? What happens if the employee has 9 children? Rare but certainly possible. What about other dependents? What if you needed to also store their birth dates? That means another 7 columns. How about gender? another 7,etc.
The answer is that the solution is not to create columns to hold "many" data, the answer is to create a table where each row represents ONE instance. So, each employee has 0 or more rows in the dependent table and each row has a foreign key that points to the employee record so you know whose dependent this is and the table contains as many columns as needed to hold the other attributes:
tblDependents:
DepID (autonumber PK)
EmpID (foreign key to tblEmployee)
FirstName
LastName
DOB
Gender
Relationship (you might need this to accommodate foster children and parents, etc. if dependents other than children are allowed..
That's the kind of thinking you need to do to design this application.
Looking at the report, it looks like Procedures and Assignments are dependent on Objectives and Outcomes are dependent on Assignments. I have no idea what Trainee work means in this context. So if you create a hierarchy of tables, you can have as many objectives as each plan needs. Each objective can have as many Procedures/Assessments as are needed and the tree continues so you can have as many outcomes as you need.
Although you can use text fields as primary keys, most people prefer autonumbers. But text fields are fine as long as this isn't going to be an app with hundreds of thousands of records. Joins are more efficient on numbers than on strings. If you go with natural keys, do NOT include autonumbers. There is no reason for them. When you have an autonumber in a table, the autonumber should be the primary key. The primary key of a table is what is used as the foreign key in a "child" table. Many newbies prefer natural keys because they like looking at related tables and seeing data rather than just numbers. the choice is yours but you need to use them correctly. I would NOT use a text PK that is longer than about 10 characters. Objectives for example are long strings so I would always use an autonumber. Same for Outcomes, etc.