It is possible, but you'll need to give us the big picture as well as the specifics you've already posted.
Relationships and portal filters can cause records to disappear from one portal and appear in another as data in the record is modified. It's also possible to set up a script that physically copies the data from one table to another and deletes or hides the original record to produce what looks like the same effect.
Don't mind the sloppy interface, just kind of slapping it all on there now to experiment. So in portal 1 you have a name entered; I am going to put a checkbox there and when checked, I want certain fields to transfer into portal 2. Currently each portal has its own table, do I need to have 1 table for ALL portals to make this work?
What you describe may work from a single table or it may require multiple tables.
I need to know more. Describe the workflow this process is supposed to support.
What does it mean in terms of your patient records when you click that check box?
What does each portal represent? Why do you need separate portals to get this job done?
Ok. The first portal will contain new patient referrals. An office clerk will fill the appropriate feilds with the patient information. Basically, this portal is recognized as "pending patients." Once the proper documentation is received, the patient is no longer pending and will be moved to portal 2:New Patients. Portal 2 represents patients that are no longer pending documents but have yet to be seen by a healthcare provider. Once they are seen, they are moved to portal 3 and 4: Follow up call and fax log, respectively. Portal 3 represents a date set when an office staff member should call the patient (courtesty call), and portal 4 represents the log of faxes sent requesting any further documentation regarding this patient.
Let's start with "pending" and "non Pending" patient contact information. I recommend that you keep this information in a single table (Call it Contacts, or Patient Info, or some such). Either a portal filter or a filtered relationship can cause a "Pending Patient" record to disappear from portal 1 and re-appear in portal 2.
The implemenation of either method is very similar. Let's say you have a status field where "pending" is auto-entered into it each time a new record in the table is created. You can format this field with a value list of one value: "Pending" and set it up as a check box field. Then each new record will appear with this value selected, but you can click the check box to clear it when it is no longer pending.
Portal Filter expressions can be setup on the two portals such as:
PatientInfo::Status = "Pending"
for portal 1
IsEmpty ( PateintInfo::Status )
for Portal 2.
This may need an onObjectModify script trigger on the check box field to perform a script with Refresh Window to help the portals to correctly update when you clear the check box value.
For the 3rd and 4th portals, it's unclear what user action you intend to take to bring up patient records in these portals. Maybe a pair of buttons in Portal 2? I'm leaning towards making these two portals separate tables as it appears you might need to schedule more than one call for a given patient and possibly log more than one fax for a given patient.
Phil, your knowledge is priceless! I have successfully set up portal 1 and 2. I think I'm going to use the same table for all portals and just add different fields/value lists to each portal to work with portal filtering.
Got into a bit of trouble here. I successfully created 4 portals where data from portal 1, jumps to portal 2 upon toggling a pop-up menu value. From portal 2->3 and 3->4. Once the data is in portal 4 and the user selects "Completed" from a pop up field, the line of data is moved into portal 5- Intake History. Portal 5 contains history of every patient that went from portal 1-4. This all works flawlessly.
The problem I have is going in reverse. For example if a user wants to put the patient back into portals 1-4 (due to a clerical error), the correct pop up fields must be selected to match filter criteria in each portal. Along the way, each portal has 2 pop up fields. 1 from the previous portal, and 1 new field (that autoenters a default value, and when is toggled, moves the data into the next portal). Since I have no idea what the user will select in portal 5.....I feel like it is not possible to come up with a follproof solution.
Have you ever dealt with this?
I've never created a relationship like this. It seems needlessly complex, I don't get the advantage to making your records "jump" from portal to portal, but it's your database to design and it should be possible to do what you have requested.
But I don't have enough details about how your pair of drop down fields work to be able to suggest a detailed solution. I would think that you could add a "back" button that performs a script to reset the needed values so that the record reappears in the previous portal.