Dear Newsgroup,

I am dealing with a problem in order to fine tuning the presentation
of information in my clinical DB (FM 8.5 adv. XP).

I have some table all related to the demographics (patient names,
age...) through an internal ID.
Everything works fine. Now I would like to improve the DB so that
starting from the first layout (demographics) anyone can see how many
exams (imaging, blood samples) were done and when.
I thought to use portals to do that and I was in facts able to get a
summary of all the imaging exams done by the single patient pretty
easily.
I would like to go further and have a summary area in the layout
reporting all the exams, blood samples etc... the patient did after
the admission. I could create many portals (one for each table) and
put them together to get the information I need, but is there a more
elegant/efficient way ?

Here we come to the Table occurences issue: although I read something
about that, still I do not know exactly what they are and what they
are for..
Finally, changing the relationships so that the tables would be
related each other and not simply to the demographics, would it
help ?

I am sorry, I understand I was not clear at all, please ask me and I
will do my best to be as more precise I can.

Thank you for any idea

Diego

In article <1185046418.721530.126270 [at] g4g2000hsf.googlegroups.com>,
Diego B <messadua [at] yahoo.it> wrote:

> Dear Newsgroup,
>
> I am dealing with a problem in order to fine tuning the presentation
> of information in my clinical DB (FM 8.5 adv. XP).
>
> I have some table all related to the demographics (patient names,
> age...) through an internal ID.
> Everything works fine. Now I would like to improve the DB so that
> starting from the first layout (demographics) anyone can see how many
> exams (imaging, blood samples) were done and when.
> I thought to use portals to do that and I was in facts able to get a
> summary of all the imaging exams done by the single patient pretty
> easily.
> I would like to go further and have a summary area in the layout
> reporting all the exams, blood samples etc... the patient did after
> the admission. I could create many portals (one for each table) and
> put them together to get the information I need, but is there a more
> elegant/efficient way ?
>
> Here we come to the Table occurences issue: although I read something
> about that, still I do not know exactly what they are and what they
> are for..
> Finally, changing the relationships so that the tables would be
> related each other and not simply to the demographics, would it
> help ?
>
> I am sorry, I understand I was not clear at all, please ask me and I
> will do my best to be as more precise I can.
>
> Thank you for any idea
>
> Diego

Relationships can be set up in many ways, so that the same tables are
related to each other several different ways in the same database. Each
set of Table Occurrences really represents one set of relationships. The
same tables can be related to each other in many different ways, by
using different Table Occurrences.

So, you could have one set of relationships in which all the various
tests etc are related to the patient table, and other relationships
tying the various result tables to each other. Then you can have layouts
based on the various Table Occurrences, that show portals to other
related Table Occurrences. And of course you can have several different
layouts based on the same main Table Occurrence, with different fields
and portals shown on the different layouts.

So you have a great deal of flexibility, really limited only by your
imagination.

You can not set a portal within a portal. Each portal can show fields
from a directly related table and fields from tables "downstream" in the
relationship diagram, but only in the same one portal. You can of course
put multiple portals in one layout, or have several different layouts
wit the different portals.

Of course, you have an initial design decision about how many tables and
what data goes in each table. That decision should be based on how you
want to use the data. Then you construct the relationship diagram and
layouts accordingly.

--
For email, change <fake> to <earthlink>
Bill Collins

> Relationships can be set up in many ways, so that the same tables are
> related to each other several different ways in the same database. Each
> set of Table Occurrences really represents one set of relationships. The
> same tables can be related to each other in many different ways, by
> using different Table Occurrences.
>
> So, you could have one set of relationships in which all the various
> tests etc are related to the patient table, and other relationships
> tying the various result tables to each other. Then you can have layouts
> based on the various Table Occurrences, that show portals to other
> related Table Occurrences. And of course you can have several different
> layouts based on the same main Table Occurrence, with different fields
> and portals shown on the different layouts.
>
> So you have a great deal of flexibility, really limited only by your
> imagination.

Thank you very much for very clear and thorough explanation, now I
have more than Idea
about table occurrences.

Unfortunately I am still not able to figure out how organize the
relationship in order to create
a Layout where all the exams (imaging, blood sample...) done by that
particular patients could be
summarized together. Unfortunately, if a Icreate a report, only the
first exam of that patient is reported.
On the other hand, portals work just fine, but I am not able to put
data from different tables in the same portal.

Thank you again for any idea about that...

Diego

In article <1185131075.041319.295900 [at] 57g2000hsv.googlegroups.com>,
Diego B <messadua [at] yahoo.it> wrote:

> > Relationships can be set up in many ways, so that the same tables are
> > related to each other several different ways in the same database. Each
> > set of Table Occurrences really represents one set of relationships. The
> > same tables can be related to each other in many different ways, by
> > using different Table Occurrences.
> >
> > So, you could have one set of relationships in which all the various
> > tests etc are related to the patient table, and other relationships
> > tying the various result tables to each other. Then you can have layouts
> > based on the various Table Occurrences, that show portals to other
> > related Table Occurrences. And of course you can have several different
> > layouts based on the same main Table Occurrence, with different fields
> > and portals shown on the different layouts.
> >
> > So you have a great deal of flexibility, really limited only by your
> > imagination.
>
> Thank you very much for very clear and thorough explanation, now I
> have more than Idea
> about table occurrences.
>
> Unfortunately I am still not able to figure out how organize the
> relationship in order to create
> a Layout where all the exams (imaging, blood sample...) done by that
> particular patients could be
> summarized together. Unfortunately, if a Icreate a report, only the
> first exam of that patient is reported.
> On the other hand, portals work just fine, but I am not able to put
> data from different tables in the same portal.
>
> Thank you again for any idea about that...
>
> Diego

I gave this a little thought after my first reply.

You chould use only one table for all the test results, rather than
multiple tables for different kinds of tests. This would give you some
more flexibility, I think.

The one table would have fields for all the different kinds of test
results, as well as, of course, a primary key field kpTestID which would
be a serial number, a foreign key field kfPatientID for relating to the
patient, a field for date of test, and perhaps a field for type of test,
and a narrative field for remarks on the test.

The Patient record could have a layout for demographic info, and a
second layout for test results.

Put a portal of related test results in the Patient Test Results layout.
Show in that portal the significant fields for the various test results.
Sort the portal by date of test.

Be aware that you can make a portal row any size, both horizontally and
vertically, so that it can hold many fields, and the fields can be
arranged any way you like in the portal row, above and below each other
as well as beside each other. The portal row can also contain layout
text, field labels and pushbuttons. For example, you could have a
pushbutton to go to the related test in a suitable layout to display all
the test information.

--
For email, change <fake> to <earthlink>
Bill Collins

On Jul 23, 5:26 am, Bill <bbcoll... [at] fake.net> wrote:
> In article <1185131075.041319.295... [at] 57g2000hsv.googlegroups.com>,
> Diego B <messa... [at] yahoo.it> wrote:
>
>
>
>
>
> > > Relationships can be set up in many ways, so that the same tables are
> > > related to each other several different ways in the same database. Each
> > > set of Table Occurrences really represents one set of relationships. The
> > > same tables can be related to each other in many different ways, by
> > > using different Table Occurrences.
>
> > > So, you could have one set of relationships in which all the various
> > > tests etc are related to the patient table, and other relationships
> > > tying the various result tables to each other. Then you can have layouts
> > > based on the various Table Occurrences, that show portals to other
> > > related Table Occurrences. And of course you can have several different
> > > layouts based on the same main Table Occurrence, with different fields
> > > and portals shown on the different layouts.
>
> > > So you have a great deal of flexibility, really limited only by your
> > > imagination.
>
> > Thank you very much for very clear and thorough explanation, now I
> > have more than Idea
> > about table occurrences.
>
> > Unfortunately I am still not able to figure out how organize the
> > relationship in order to create
> > a Layout where all the exams (imaging, blood sample...) done by that
> > particular patients could be
> > summarized together. Unfortunately, if a Icreate a report, only the
> > first exam of that patient is reported.
> > On the other hand, portals work just fine, but I am not able to put
> > data from different tables in the same portal.
>
> > Thank you again for any idea about that...
>
> > Diego
>
> I gave this a little thought after my first reply.
>
> You chould use only one table for all the test results, rather than
> multiple tables for different kinds of tests. This would give you some
> more flexibility, I think.
>
> The one table would have fields for all the different kinds of test
> results, as well as, of course, a primary key field kpTestID which would
> be a serial number, a foreign key field kfPatientID for relating to the
> patient, a field for date of test, and perhaps a field for type of test,
> and a narrative field for remarks on the test.
>
> The Patient record could have a layout for demographic info, and a
> second layout for test results.
>
> Put a portal of related test results in the Patient Test Results layout.
> Show in that portal the significant fields for the various test results.
> Sort the portal by date of test.
>
> Be aware that you can make a portal row any size, both horizontally and
> vertically, so that it can hold many fields, and the fields can be
> arranged any way you like in the portal row, above and below each other
> as well as beside each other. The portal row can also contain layout
> text, field labels and pushbuttons. For example, you could have a
> pushbutton to go to the related test in a suitable layout to display all
> the test information.
>
> --
> For email, change <fake> to <earthlink>
> Bill Collins- Hide quoted text -
>
> - Show quoted text -

Unfortunately creating only one table for all the exams would be a
little be confusing because of the different dates the patient can
have a particular exam
but not another and for the repetition of some exams but not others.
Moreover, all the tables and layouts have been already defined and
changing everything would
require a lot of time...
However, I was able to create a portal that is somewhat similar to
what I wanted at the beginning, although I think the only way to
create what I thought
is to have only one table for the exams...

Thank you so much for the support !

Diego