Hi All,

I'm going to try and explain this as best I can, so feel free to ask questions if something is unclear!  I am building a database for clinical mental health.  In working with clients, users will need to document a variety of forms using different measures, like an MSE, PHQ, DA, and other "forms" (the abbreviations shouldn't be relevant).  On the client's dashboard, I'd like a portal showing all of their documents/forms that have been entered, but I dont want to have individual portals for each type of form, I'd like them to all be shown on the same portal.  What would be the easiest way to do this?  Is the best way to add fields from ALL of the forms to one table, and then filter which fields are shown during creation based on the form the user wants to add, and then just show timestamp, user, etc, on the portal?  Or is there a way that I should make each form its own table, and if so, how would I get all of those to show on the same portal?  Looking for ease of use for the users and whichever will preserve the solution's performance.

Thanks for the help!

Have a form table with all the fields that are shared by all the forms. Also have a form subtype table for each unique form, with just the fields unique to that form. The form and formsubtype tables  share the same primary uuid. When you create a formsubtype, you also create a form. You can then display all the  forms in a portal. 

Great!  To add a view button to the portal, would I make my script something like this?

If DocType = "MSE" 
Go to related record from Subform|MSE using window _________
Else If DocType = "DA"
go to ..............

 

There are quite a few possible solutions here you could choose from:

1. A single "wide" table for all forms having all possible fields (as suggested in your question). You could use a dedicated layout with the relevant fields for each type of form. This has the advantage of being quite easy to implement.
2. A separate table for each type of form. You would not be able to show all patient's form in a portal, but there may be other ways.
3. A single table for all forms, with all form data stored in a sub table as name/value pairs - a.k.a the entity–attribute–value data model.
4. A single table of all forms, with form-specific data stored in subtables (one subtable for each form type) - a.k.a the supertype/subtype data model. This may be the most "correct" solution, but it is not easy to implement in Filemaker.

 It's hard to say which one would be best for you with so little information given.

--
P.S. Please update your profile to show your version and OS.

 

Edited June 9, 20196 yr by comment