Export overlap

[dougd59]

I have created a FMP12 solution for a doctors office.  When a patient comes in for an exam, they automatically get a recall date; typically a year from their visit.  I would like to do the following:

 

At any given time, export a list of patients who are due to be recalled.  Then, lets say a month later, export another list, but exclude any patients who were recalled in previous exports, so there's no overlap.

 

Heres where it gets a bit complicated.  In, say, 3 months of exporting as above, I would like to export patients who haven't responded to their first recall, as well as new recalls.  Then, after a set amount of recalls (3), if the patient still hasn't returned to the office, to discontinue that patient being exported.

 

Also, if a patient does respond to the recall and return to the office for their annual exam, they would have a new recall date that would permanently supercede  their previous one.

 

Any and all help would be appreciated.

[LaRetta]

Hi Doug, welcome to FMForums!!

 

What do you plan to do with the exported data?  Normally, we just provide a layout where, automatically, the upcoming visits appear in the portal .  All of the rules you've outlined can easily be applied.  

 

I would assume that, when a Patient does visit, the recall date should be reset to one year ahead again.  I am sure Patient's do not keep appointments exactly on their one-year anniversary, right?  So a completed visit should reset the RecallDate.  You do have a Patients table and an Appointments table, is this correct?  And are they related on a unique, meaningless primary-to-foreign key?

 

Would it be nice that, every time a User signs on, they see what is due from all the categories you've mentioned (according to your rules) and they are coded to easily identify which are CRITICAL?  And further, an email or text message could be generated as a Notice to these people or your User could be taken to their details to follow up.

 

Deactivating a Patient is a simple find or Go To Related Record which can be a single button, User is asked to verify the Patient deletion and script performs the action and returns the User to their layout.

 

Exporting all those different sets of data seems overly-complex given FileMaker's ability to do it all for you.  Feel free to ask questions or explain more and we'll help you come up with just what you need.  :-)

Added:  Normally deletions are not recommended particularly on a primary entity such as Customer or Patient.  This is because they will have activity and history in the form of related records and you do not want to orphan those records where they cannot know which Patient they belong to.

 

Better to flag them as Inactive.

Added also:  

 

Since Patients will all have a different RecallDate, you do not want to have to script something and generate an export or even print-out every time someone comes due.

 

Instead, by using a portal, you can set your rules with a 5-day grace period so you will see those COMING due, as well as the past dues.  A table of Appointments means you will know when they last visited so it will be automatic.  It is the power of relational databases.   :-)

When I indicate 'reset the RecallDate', I mean apply that functionality.  I do not see the need to actually set a date field with the next upcoming date but rather would suggest relational approach over scripting.  But much would depend upon your existing structure and more information. 

[Lee Smith]

Hi Doug, and welcome to the Forum,

 

I moved your topic from "FileMaker Pro 12" to "Importing & Exporting” because, the General Topic areas for the different releases are restricted to the discussion of the Tool, Functions, Features that were new with that particular release of FileMaker.

 

If you have any questions about this action, please just contact me by Private Message.