the consequences of putting a value in
> this field
> for a patient that is not an inpatient.
>
> - Original Message -
> From: "Jim Self" <[EMAIL PROTECTED]>
> To:
> Sent: Tuesday, February 15, 2005 8:07 PM
> Subject: RE: [Hardhats-members] How to
ps you have misunderstood the situation." - -
D.K.Moran
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of
steven mcphelan
Sent: Wednesday, February 16, 2005 7:53 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a
f these fields were originally designed for
inpatients. I do not know the consequences of putting a value in this
field
for a patient that is not an inpatient.
- Original Message -----
From: "Jim Self" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, February 15, 2005 8:07 PM
Subject: RE
Kevin, you have gained good insights into VistA through your dogged
exploration of it.
Other systems built on a relational database likely have business rules
that are not in the database itself, so the business logic is important
for maintaining the tables properly. Just going in with a diffe
his field
for a patient that is not an inpatient.
- Original Message -
From: "Jim Self" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, February 15, 2005 8:07 PM
Subject: RE: [Hardhats-members] How to obtain a write access of "~" ?
> I would appreciate more detailed
Since this seems to be a new issue for Kevin and he has been crawling around
in VistA for a while now, is this sort of field not rare as hen's teeth?
I would think that some internal policy in the VA might be responsible for
locking up this field. For instance, perhaps they did not want patient
It seems to me that VistA is not just a database, with
secondarily important routines to adjust that data.
Instead, it seems that it is both. Thus this "locked"
database field is not supposed to be altered except
through the proper channels (the program code.)
So it may well be problematic tryin
I would appreciate more detailed discussion on this point if possible. It would
seem from
what you write that such fields cannot be properly edited from the Fileman DBS
API. If so,
that would seem to present a severe impediment to any attempts to put a more
modern
general database driven user in
cross references in the
> > DD
> > >covered every business rule associated with a field but that is not
> > the
> > >case. Some of the rules are so complex and so dependant on the data
> > >entry situation that whole sets of routines are required to carry
>
Nancy,
I think I opened a can of worms on this one. I was
assuming that an out patient could also have an
attending physician. But apparently not.
I think this issue is going to be more hassle than I
won't to mess with right now.
Thanks for everyone's help!
Kevin
--- Nancy Anthracite <[EMAIL
ect: Re: [Hardhats-members] How to obtain a write access of "^"
> ?
> >
> >Stephen;
> >
> >Then that sounds like the loading of this field is programatic (data
> >loaded
> >at the time of the action being recorded) and doesn't use Fileman to
>
ge-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg
Woodhouse
Sent: Monday, February 14, 2005 10:58 AM
To: hardhats-members@lists.sourceforge.net
Subject: RE: [Hardhats-members] How to obtain a write access of "^" ?
Does this trick offer any advantages over using t
rule associated with a field but that is not
> > the
> > case. Some of the rules are so complex and so dependant on the
> data
> > entry situation that whole sets of routines are required to carry
> out
> > the appropriate data updates and linkages.
> >
> >tjh
-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Chris
> Richardson
> Sent: Monday, February 14, 2005 2:34 AM
> To: hardhats-members@lists.sourceforge.net
> Subject: Re: [Hardhats-members] How to obtain a write access of "^&quo
y 14, 2005 10:22 AMTo:
hardhats-members@lists.sourceforge.netSubject: Re: [Hardhats-members]
How to obtain a write access of "^" ?
That should have been 'it is a way', not 'it was
a want'. If only I could keep my typing buffer in sync with my thinking
buffer ;-)Greg Kreis wro
re required to carry out
the appropriate data updates and linkages.
tjh
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Chris
Richardson
Sent: Monday, February 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members]
Monday, February 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Stephen;
Then that sounds like the loading of this field is programatic (data
loaded
at the time of the action being recorded) and doesn
ruary 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Stephen;
Then that sounds like the loading of this field is programatic (data
loaded
at the time of the action being recorded) and doesn't use File
of it.
- Original Message -
From: "steven mcphelan" <[EMAIL PROTECTED]>
To:
Sent: Sunday, February 13, 2005 7:50 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
> If a field is write protected with the "^" then no DUZ(
If a field is write protected with the "^" then no DUZ(0) will allow you to
edit that field using Fileman enter/edit.
- Original Message -
From: "Nancy Anthracite" <[EMAIL PROTECTED]>
To:
Sent: Sunday, February 13, 2005 9:57 PM
Subject: Re: [Hardhats-memb
Maybe it is because you don't have a patient who has been admitted! Note that
it says inpatient below.
On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote:
> I noted that only active providers are allowed, so do your docs have the
> PROVIDER key and the only thing I could see that might
I noted that only active providers are allowed, so do your docs have the
PROVIDER key and the only thing I could see that might have to do with that
and show activity was the PERSON CLASS, in file 200, which has an expiration
date which I believe you can leave blank. Do your docs have a person
I also thought @ was a master access setting. But
here is a screen log of what I am seeing.
GTM>zwr DUZ
DUZ=90
DUZ(0)="@"
DUZ(1)=""
DUZ(2)=69
DUZ("AG")="O"
DUZ("AUTO")=1
DUZ("BUF")=1
DUZ("LANG")=1
GTM>d ^XUP
Setting up programmer environment
Terminal Type set to: C-VT102
Select OPTION NAME: d
Actually, the @ is a superaccess that should be sufficient for any
situation, no matter what the file DD, read, write, delete access code
is. In other words, you should not have any difficulty doing anything
in any file. Are you having difficulty or are you just anticipating
having difficult, i
Take a look at the FILE MANAGE ACCESS CODE field in file 200. Maybe you can
put a ^ there with D P^DI and then see what happens.
On Sunday 13 February 2005 05:14 pm, Kevin Toppenberg wrote:
> Hello all,
>
> I want to edit fields .104 (PROVIDER) and .1041
> (ATTENDING PHYSICIAN) in file 2 (PATIEN
As you might guess, that's a trick that is sometimes employed to
discourage unauthorized "fiddling" with sensitive files. Off the top of
my head, I'm not sure if Fileman will complain if you set DUZ(0)
programmatically to "^" before attempting an update, but I believe this
will work.
--- Kevin Top
Hello all,
I want to edit fields .104 (PROVIDER) and .1041
(ATTENDING PHYSICIAN) in file 2 (PATIENT file). I
have a fileman code of "@"
In the data dictionary, these two fields have a code
of ^ required. I assume this means that my DUZ(0)
must contain a ^. This is normally loaded (I believe)
f
27 matches
Mail list logo
