|
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 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 "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,
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
|
