I am dealing with two issues here. One is the feedback to the VistA-Office folks who have to support roll and scroll and maybe will be making a GUI. The other is the rest of us.
As for the templates, from what I understand, it is tricky to get templates to enter data back into the system other than by making something like a document that you can look at. One is something using the feedback method from clinical reminders. Can anyone comment on other ways to use the standard template to put data into fields? On Sunday 12 December 2004 01:22 pm, Kevin Toppenberg wrote: > Nancy, > > There are MANY fields that one would not want to have > to wade through when entering registration data. I > think Norman Dodd mentioned to me that he set up a > template or used screenman to ask just relevant > questions. > > Thus you don't want to depend on Fileman to decide > which fields you do and don't want to ask. It would > probably be better to figure out what you want, and > then create an interface of some kind to get that > information. > > Kevin > > --- "Nancy E. Anthracite" <[EMAIL PROTECTED]> > > wrote: > > Now that you guys have got this all figured out, > > suppose you wanted fields to > > be conditionally displayed to the registration > > clerk? Say you have a child > > under two and you would like to know the date the > > child was due to be born so > > that it can be used in calculations of prematurity > > and postmaturity - it is > > called the EDC or estimated date of confinement, but > > you don't care to > > display that as a registration question any more > > after age two? What > > determines if an item is displayed at all? > > > > > > On Sunday 12 December 2004 06:14 am, Kevin > > > > Toppenberg wrote: > > > Thanks Steven, > > > > > > Comments below: > > > > > > --- steven mcphelan <[EMAIL PROTECTED]> > > > > wrote: > > > > A required field is just that. When you get to > > > > that > > > > > > field in roll-n-scroll mode you must enter a > > > > value. > > > > > OK, I think I understand. Required fields are > > > required in the roll-n-scroll mode. But they are > > > > not > > > > > required when using the UPDATE^DIE method of > > > > creating > > > > > the records. As per our other post, we were able > > > > to > > > > > create a record with just the .01 field specified > > > > > > > > An identifier has multiple purposes and > > > > > > > > interactions. You can mark a field an > > > > identifier > > > > > > using the Fireman Utility option. Identifiers > > > > can > > > > > > be set up two ways, to display when lookups are > > > > done > > > > > > or to not display when lookups are done. In > > > > either > > > > > > case, when a new entry is added to a file using > > > > the > > > > > > roll-no-scroll method, Fileman will prompt the > > > > user > > > > > > for values for all fields marked as identifiers. > > > > If > > > > > > a field is also required, then in that > > > > roll-n-scroll > > > > > > method you must enter a value for that > > > > identifier > > > > > > field in order to create a new record. Required > > > > identifiers was a way to historically provide > > > > key > > > > > > functionality in the roll-n-scroll days. > > > > > > Thanks. I found the Identifier menu option and > > > > played > > > > > with it. Another thing learned about fileman. > > > Thanks! > > > > > > > Since then Fileman has actually implemented KEY > > > > on a > > > > > > file that is in a more like file KEYS in other > > > > databases. There are pro and con arguments as > > > > to > > > > > > whether a file record should have KEYS or > > > > required > > > > > > identifiers depending upon what you want to do. > > > > If > > > > > > you have a few fields in a file where the > > > > combination of those fields should ALWAYS be a > > > > unique combination among all the records in that > > > > file then using Fileman KEYS is the way to go. > > > > But > > > > > > for any file that is KEYed, you must always > > > > provide > > > > > > all those field values when creating a new > > > > record. > > > > > > If you process involves setting up a stub record > > > > that will populate those "key" fields later, > > > > then > > > > > > you cannot use Fileman KEY. It you want the > > > > DBMS to > > > > > > manage uniqueness for you, use KEY. If your > > > > process > > > > > > is going to manage uniqueness, then you may not > > > > want > > > > > > the file to have KEYs. > > > > > > I hadn't noticed the "Key Definition" menu option > > > before, but I see now that one can create a key > > > > for a > > > > > file this way. > > > > > > Thanks again! > > > > > > Kevin > > > > > > > ----- Original Message ----- > > > > From: Kevin Toppenberg > > > > To: [EMAIL PROTECTED] > > > > Sent: Saturday, December 11, 2004 7:31 AM > > > > Subject: Re: [Hardhats-members] Are "required" > > > > fields really required? > > > > > > > > > > > > Thanks for both of your replies. I still have > > > > much to learn about Fileman. I don't know the > > > > difference between a required field and a > > > > required > > > > > > identifier. I also don't know how to explore > > > > about > > > > > > keys. I can't find a menu option that discusses > > > > keys--just cross-references. > > > > > > > > Also, is seems that UPDATE^DIE can create a > > > > record > > > > > > that doesn't have required fields. But the > > > > stimulus > > > > > > for this question was the error I was getting > > > > about > > > > > > missing required fields (see other post). So > > > > does > > > > > > UPDATE check for these missing requirements or > > > > not? > > > > > > I have been trying to figure out how I can > > > > learn > > > > > > this stuff without bugging you guys all the > > > > time. > > > > > > I'm going to try reading the fileman manual > > > > again. > > > > > > I don't think I could understand what I was > > > > reading > > > > > > last time, but maybe I could get farther this > > > > time. > > > > > > Thanks again > > > > Kevin > > > > > > > > steven mcphelan <[EMAIL PROTECTED]> > > > > wrote: > > > > Is it true about that wrinkle for Required > > > > fields or is it only a valid > > > > statement for Required Identifiers? UPDATE > > > > should not care about REQUIRED > > > > fields unless a field is either an > > > > identifier or > > > > > > that field is included in > > > > the FDA array. > > > > > > > > ----- Original Message ----- > > > > From: "Greg Woodhouse" > > > > To: > > > > Sent: Friday, December 10, 2004 10:05 PM > > > > Subject: Re: [Hardhats-members] Are > > > > "required" > > > > > > fields really required? > > > > > > > > > First of all, a field may be required in a > > > > > > > > subfile, which means that > > > > > > > > > you have to enter a value when creating a > > > > > > > > subrecord. Normally, > > > > > > > > > "required" means that Fileman won't let > > > > you > > > > > > just hit and skip > > > > > > > > > the field. The DBS calls add a new > > > > wrinkle, > > > > > > because UPDATE^DIE won't > > > > > > > > > let you omit a required field (you get an > > > > > > > > error). However, "Classic" > > > > &! gt; Fileman only allows you to edit a > > > > record > > > > > > field by field (in most > > > > > > > > > cases), so it actually possible to create > > > > a > > > > > > record with a required > > > > > > > > > field not valued. As a result, in some > > > > > > > > applications, you will see > > > > > > > > > fields that are required when they should > > > > only > > === message truncated === > > > > > __________________________________ > Do you Yahoo!? > Dress up your holiday email, Hollywood style. Learn more. > http://celebrity.mail.yahoo.com > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Nancy Anthracite ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
