Understanding data entry forms vs. exact forms & how to create a client recordID field by combining partial data from other fields.

Yes please help with the medical ID formula!  I'm a clinical supervisor who is trying to develop the company's EHR system on the weekends so I have really no experience w/computer systems or programming.  This is all new to me & I have very limited time to try & teach myself how to do this stuff so I'd really appreciate the help.  As for the ap, I was already looking into that exact one & most likely will use it as long as it doesn't cost me too much or cause any type of problem w/my company's current Quickbase setup.  The systems guy created a "Clinical" ap and gave me administrator status to play around w/stuff this weekend so I'm already looking into that ap.

Also, are you in any way affiliated with Juiced or did you just suggest that ap because you've had good reviews?  The reason that I'm asking is I have a concept of what I'm trying to accomplish & believe that ap would actually be a very solid investment for the company, but I'd have to be knowledgeable enough about its features and how they would benefit our process to advocate for consideration regarding it's purchase.  If you have any stake in that ap would you be able to answer some other basic questions to educate me further so I can adequately explain it's value to my systems guy?  If not, could you point me in the direction of where I could find someone who could help me with this?

I�m not affiliated with Juiced. I�m a Quick Base Solutions Provider who has implementned Juiced Exact Forms Plus dozens of times for my clients.

I can answer questions here or you can contact Juiced directly. Typically when my clients need a customer facing firm as opposed to just for internal use, then I help them implement EF+ or give them training tips on how to implement themselves.

The setup allowed for fields to be inserted in a Form and also embedded sub tables, typically child tables.

I sincerely appreciate the guidance & we have a meeting scheduled for next Tuesday where I'll introduce the EF+, because it seems like it will really simplify what I'm trying to accomplish.  Right now I'm still trying to wrap my head around the table relationships setup that I need to effectively actualize the system.  They have already created a parent "clients" table with a new client input form for the admissions person to input new client data.  I'm trying to build out the system so that all the new client data input during the admissions/screening appointment is populated into the appropriate places throughout the respective admissions intake documents required in the medical record (i.e. client referral form, client FACE sheet, client release of information forms, patient registration form, screening form, etc.)  Currently the admissions person is having to handwrite the same information (client name, DOB, insurance info,etc.) into each form, which is extremely inefficient.  I saw in the youtube video on EF+ that they had created at document templates table & a document template subtables table.  I'm wondering if I should be creating an admissions intake forms table that is the child of the clients table but the parent of intake documents subtables maybe one for each separate intake document form? But my gut tells me that there's a much more efficient way to structure this.  Maybe just create the admissions intake documents table with all the fields that would be on each form (obviously none duplicated) & then just create an exact form for each required intake document w/the specific fields required that is linked to that table?  I'm still trying to understand how to form basic table relationships because it seems like most of the information fields for the various forms could be linked in from other tables such as the client table, insurance policy table, address table, etc., but then I'm not understanding where the user input for the rest of the data is performed.  Sorry if I'm not making much sense but any continued guidance would be greatly appreciated.

It�s difficult to help you lay out the best structure for your app on this forum. Obviously one on one would be better.

In general, you need to think of each table in terms of information that you only want to enter once.

So for example, yes you need a Patient table. Then likely, the same patient could get admitted more than once. So then you would have an admissions table where One parent has Many Admisisons. Then look up all the patient info down to the Admisisons table so that there no duplication of data entry.

I can continue to answer questions son this community forum, but if you decide that you are at a point where you would like one on one Assistance and coaching tips, then you can contact me via

QuickBaseCoach.com