RE: [Hardhats-members] Pointers and keys
The new style cross reference was the key I meant to reference in the original post. I should have been clearer in that reference. The unique ID we create in the SD appointment is a number commonly called charge slip number in our practice. It may be used an ID for numerous activities. DOT(truckers exam) General physical Spirometry Audiometry, Lab tests , Xray, etc Injury visit (Workers Compensation) And the list can be as long as your imagination. We need some way to bind that all together in a common identification that everyone may use to reference activity that typically occurs on a unique date. Another way we could do this is let the date, combined with a new style cross reference creating a unique ID, handle the uniqueness. I have been using the above scheme since 1970, always hoping to find a better method. So far, I always wind up back at the charge slip# as the method. I was hoping to fine something better this time around. This time I was hoping to use the new styled cross reference (created with combination of charge slip# and patient name or date) as the unique ID. Backward pointer was a considered to reference (from patient file) anything pointing to patient and typically used only in reports. Sort patient file and address the DOT exams pointing to a unique patient not a burning need. I am sill listening. Thanks, thurman From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Woodhouse Sent: Friday, July 29, 2005 11:05 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Pointers and keys There are applications that use semantically meaningful values for the IEN, but I don't recommend doing this. In fact, I would recommend rather strongly that you do not do this. However, you CAN ensure that a field such as .01 be unique. You need to create new style cross-reference, and this will be done automatically for you if you make this field into a key. Being clever is seldom a good idea, but you can even make the B cross-reference the uniqueness index underlying the key if you really want to. I don't know if this is responsive to your question, but I've worked with a number of files that attempt to have semantically meaningful .01 fields, and that really buys you very little and does cause a bunch of grief in the long run. Can you explain a little more what you mean by backward pointer. Are you wanting to quickly identify the (sub)records in another file pointing a record in your file? === Gregory Woodhouse [EMAIL PROTECTED] A hero is no braver than an ordinary man, but he is brave five minutes longer. -- Ralph Waldo Emerson On Jul 29, 2005, at 8:02 PM, Thurman Pedigo wrote: With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as DOE,JOHN . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
[Hardhats-members] Pointers and keys
With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as DOE,JOHN . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
RE: [Hardhats-members] Pointers and keys
If your TESTFILE field .01 is a pointer to another file, then the DOE,JOHN cant be the internal value in the .01 field. DOE,JOHN could be in the .01 field in the file TESTFILE is pointing to. And, yes, you should be able to have a unique number in field 2 be a KEY to TESTFILE. If I recall correctly just tell FileMan when you create a new-style cross-reference on field 2 that you want it to be a unique key. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thurman Pedigo Sent: Friday, July 29, 2005 8:03 PM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] Pointers and keys With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as DOE,JOHN . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
Re: [Hardhats-members] Pointers and keys
Thurman; How do you know that the number that you are assigning is unique? What does the unique number represent? An encounter idwhich each individual may have a number of these? Why not let Fileman assign the unique identifier (like it already does for the patient file). Then the name doesn't need to be the .01 field. You can always define a cross reference for the field you want to use for the name.. Unfortunately, I can't see how you will keep the unique IDs straight when you supply the name second. It sounds like you are making more work for yourself. I hope this helps. Chris - Original Message - From: Thurman Pedigo To: hardhats-members@lists.sourceforge.net Sent: Friday, July 29, 2005 8:02 PM Subject: [Hardhats-members] Pointers and keys With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as DOE,JOHN . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
RE: [Hardhats-members] Pointers and keys
How do you know that the number that you are assigning is unique? I let FileMan create the unique field via appointments. We print encounter forms from the appointment process incrementing the encounter number each time we create a new form (which declares the ID). I can see problems if we get large enough perhaps the increment could have a head crash. And I have experienced the hazards of using this scheme. We have used a decimal (12345.1) to deal with more than one encounter in the same day, or for instances where we need to bill multiple entities ie one group pays for injury visit, another group pays for drug screens. That is a little simplistic, but it allows us to bundle in a way that find the various entities into one place to look for what went on. This if obviously a most opportune time to chose the solution, as I upgrade FileMan to VistA. I still have a little trouble thinking through how to aggregate the multiple billing instances and changing mindset of 15 years generating encounter numbers. That patient .01 index looks pretty challenging as well. I appreciate any additional guidance. Thanks, thurman From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Friday, July 29, 2005 9:35 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Pointers and keys Thurman; How do you know that the number that you are assigning is unique? What does the unique number represent? An encounter idwhich each individual may have a number of these? Why not let Fileman assign the unique identifier (like it already does for the patient file). Then the name doesn't need to be the .01 field. You can always define a cross reference for the field you want to use for the name.. Unfortunately, I can't see how you will keep the unique IDs straight when you supply the name second. It sounds like you are making more work for yourself. I hope this helps. Chris - Original Message - From: Thurman Pedigo To: hardhats-members@lists.sourceforge.net Sent: Friday, July 29, 2005 8:02 PM Subject: [Hardhats-members] Pointers and keys With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as DOE,JOHN . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
RE: [Hardhats-members] Pointers and keys
Thanks Dumb! I wasnt carrying it far enough and creating a downstream file for the pointer./t From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron Schlehuber Sent: Friday, July 29, 2005 9:22 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Pointers and keys If your TESTFILE field .01 is a pointer to another file, then the DOE,JOHN cant be the internal value in the .01 field. DOE,JOHN could be in the .01 field in the file TESTFILE is pointing to. And, yes, you should be able to have a unique number in field 2 be a KEY to TESTFILE. If I recall correctly just tell FileMan when you create a new-style cross-reference on field 2 that you want it to be a unique key. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thurman Pedigo Sent: Friday, July 29, 2005 8:03 PM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] Pointers and keys With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as DOE,JOHN . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
Re: [Hardhats-members] Pointers and keys
There are applications that use semantically meaningful values for the IEN, but I don't recommend doing this. In fact, I would recommend rather strongly that you do not do this. However, you CAN ensure that a field such as .01 be unique. You need to create new style cross-reference, and this will be done automatically for you if you make this field into a key. Being "clever" is seldom a good idea, but you can even make the "B" cross-reference the uniqueness index underlying the key if you really want to. I don't know if this is responsive to your question, but I've worked with a number of files that attempt to have semantically meaningful .01 fields, and that really buys you very little and does cause a bunch of grief in the long run.Can you explain a little more what you mean by "backward pointer". Are you wanting to quickly identify the (sub)records in another file pointing a record in your file? ===Gregory Woodhouse[EMAIL PROTECTED]"A hero is no braver than an ordinaryman, but he is brave five minutes longer."-- Ralph Waldo Emerson On Jul 29, 2005, at 8:02 PM, Thurman Pedigo wrote:With so much excitement, I hate to post such a mundane question as pointers and keys. However, I have never been able to get KEYs to perform in the way I expect. I want to have file TESTFILE point to field .01 of another file so that I can use backward pointers. Further I would like to create a record in the file with a unique # to main the uniqueness of multiple instances of the same name in .01 field of the file. It seems I should be able to enter a unique # such as 12345 without having to encapsulate a new entry as the name file in quotes. For instance if the name is DOE,JOHN in the referenced field, I would like to enter 12346 (in field #2) to create a unique entry, then enter DOE,JOHN in field .01, separate from the first record than the 12345 and still allow the .01 field in this record to exist as “DOE,JOHN” . Is this workable? Or is this just bad policy? I know this is sort of confused and will be difficult to sort out. Basically, I want to have field 2 as the UNIQUE ID for each record in TESTFILE, and .01 field point to a sort of parent file. Thanks, thurman
Re: [Hardhats-members] Pointers and keys
Sorry...I meant to say semantically meaningful IENs. Certain IFCAP files do this, and it really is a pain in the neck. === Gregory Woodhouse [EMAIL PROTECTED] Education is a progressive discovery of our own ignorance. --Will Durant On Jul 29, 2005, at 10:05 PM, Gregory Woodhouse wrote: but I've worked with a number of files that attempt to have semantically meaningful .01 fields, and that really buys you very little and does cause a bunch of grief in the long run. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
