Sir,
We are able to install GT.M onto hard disk. We used Morphix (
Distributed along with OpenVista CD ). Afterwards,
we couldn't go forward. Kindly, suggest the way to execute a openVista
module.
Thanks in Advance,
Srikanth.M.L
begin:vcard
fn:Lakshmi Srikanth
n:Srikanth;Lakshmi
If you look on the Wiki for WorldVistA at
http://openforum.worldvista.org/~forum/index.php?title=Main_Page , there are
some installation instructions to get you started. There is also some more
information on the Hardhats web site at http://www.hardhats.org. You might
be especially
Check out Kevin's site http://www.geocities.com/kdtop3/
Anna
- Original Message -
From: srikanth [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Tuesday, April 19, 2005 11:50 AM
Subject: [Hardhats-members] How to execute OpenVista Modules
Sir,
We are able to
Sir,
We are able to install GT.M onto hard disk. We used Morphix (
Distributed along with OpenVista CD ). Afterwards,
we couldn't go forward. Kindly, suggest the way to execute a openVista
module.
Thanks in Advance,
Srikanth.M.L
---
This
I am new to Vista; have installed Cache and Vista, and it seems to be
running OK. What I'd like to know is how easy it is to configure Vista
tables; for example, we would not need SSN, VA numbers, combat service
location etc for patients but we might need other fields which aren't
present in the
It is not wise to remove tables and fields unless you are really sure
that you have also removed all the references to them. However, unlike
relational databases that have fixed, pre allocated blocks for storage,
Cache does not pre-allocate storage, and if a field is not used, it does
not take
I guess a better question... and one that I am thinking of... is there a
way to set up defaults... so that certain questions aren't even
asked...
Such as Veteran status ... etc.
I may be wrong... (and please correct me..)
Is the proper way to do this:
To create a template in Fileman?
And then
Templates and ScreenMan (and I guess Listmananger) handle this nicely, as
long as the field isn't required. I am experimenting with removing
requirement in the patient file. So far - so good. It looks as though the
system allow some pretty sparse fields and still save that data. FileMan
will surly
The design of the VistA system anticipated the requirement to create new
data elements (fields) indefinitely into the future. VistA provide for a
formal method of allowing for the addition of data elements without adverse
impact. It is, however, a matter for competent (master craftsman)
Could you please address the poison in a little more detail, starting with the
part of not using field. Could you reassign the name of the field and change
the length, for instance, for the SS number to create the patient record
number that would continue to function properly?
On Tuesday 19
Anna,
I don't know how this system works. I wonder if Marc A., who I believe works with the IHS system, could explain this.
KevinAnna Joseph [EMAIL PROTECTED] wrote:
That's just the captioned output of some patients in the implementation we have here. These patients we had entered (not
I wouldn't do that. Yes, you could change the database parameters so that other numbers could be stored in it. But then you have to think about every single application already written that might access that datafield. What assumptions have been made about the length of the number. If it was
The KIDS builds on the VA ftp site are
CRLF format. Have you performed the DOS 2 Linux reformatting to
knock off the CRs?
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Reed
Sent: Monday, April 18, 2005 7:14
PM
To:
Also, the OPEN PARAMETERS are wrong. The value "WNS" is
Cache-specific. That may not matter. If it still doesn't work after
removing "WNS" Iwould suggest simulating what ^XPDIL does, to
troubleshoot. In other words, from the GT.M command prompt -
S
We can look and comment and see if VistA will fit the mold that lots of docs
are going to want it to fit in before agreeing to adopt it.
Commission issues proposed EHR certification requirements
By Joseph Conn
The Certification Commission for Healthcare Information Technology has
released for
The option was running when the system was
shutdown, but when the system was restarted there was nothing to tell TaskMan
to restart the job. The option checks for the ACUITY TASK NUMBER in the NURS
PARAMETER file 213.9 youll find that there is a now out of date
task number in that field.
Re: Rx dispensing information.
It appears the code is checking the cross references for RELEASE DATE/TIME and
FILL DATE, but checking nothing on the DISPENSED DATEs. There are likely
some additional steps in the process of dispensing that have to
be completed. Sorry I cant be of more
I hate subscription links.
http://www.cchit.org/publiccomment1.htm
On Tuesday 19 April 2005 09:18, Nancy Anthracite wrote:
We can look and comment and see if VistA will fit the mold that lots of
docs are going to want it to fit in before agreeing to adopt it.
Commission issues proposed
I was wondering if there is a limit to how many Secondary menus can be
assigned to a user?
--
Mark Street, RHCE
http://www.oswizards.com
--
Key fingerprint = 3949 39E4 6317 7C3C 023E 2B1F 6FB3 06E7 D109 56C0
GPG key http://www.oswizards.com/pubkey.asc
From: Nancy Anthracite [EMAIL PROTECTED]
Reply-To: hardhats-members@lists.sourceforge.net
Date: Tue, 19 Apr 2005 10:55:04 -0400
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan
Could you please address the poison in a little
There's no limit.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Street
Sent: Tuesday, April 19, 2005 12:21 PM
To: hardhats-members@lists.sourceforge.net
Subject: [Hardhats-members] How many Secondary Menus can be assigned?
I was wondering if there
So I guess that means that one cannot entirely rely upon the cross reference
information in the data dictionary to track down the potential interactions
with other packages, hence the desire of many to carefully reengineer VistA
before considering an attempt to replace it?
On Tuesday 19 April
The answer, once and for ever more, if the set of items being considered are
a set of VA File Manager 'entries'--or in other words VA FM tables (files)
then the list if entries is indefinitely long.
VA FM uses an internal global method known as double subscripting to
designate where a 'table'
From: Nancy Anthracite [EMAIL PROTECTED]
Reply-To: hardhats-members@lists.sourceforge.net
Date: Tue, 19 Apr 2005 16:14:13 -0400
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan
So I guess that means that one cannot entirely
I agree with Richard on this. Changing the DD definition of a commonly used
field like
SSN, would most likely have some unwanted, and unintended side-effects.
Code that references SSN, would not always be in the Data Dictionary. It
would also be in routines, sometimes obscured by indirection.
No.
The SECONDARY MENU is a subfile, and hence may have an arbitrary number
of entries.
Yes.
Practically, the SECONDARY MENU is a pointer (reference) to the main OPTION
file, so if there are 89,013 entries in the OPTION File, there can only be
89,013 unique entries in the SECONDARY MENU. Of
David, let me correct a slight inaccuracy in what you stated. If the nested
table of Secondary Options were DINUMed you would be correct in stating
that the total number could not exceed the number of entries in the Option
file. However, the value of the field is not tied to the value of the
I don't either, but I recall some things about
it. If you use the VA FOIA there is cross reference on the SSN that stuffs
the SSN into the HRN. The interesting thing is that it violates the input
transform on the HRN field. If you are not going use SSN you need a
different way to keep files
That is interesting.
St Petersburg is adjacent to Largo, which is famous for implementing the
city IT infrastructure on Linux, at significantly lower cost than
neighbours.
It is also near the scene of some debacle in a previous attempt to
replace VistA with a more profitable system, is it not?
I would say it is not good idea to try to change the name of field .09 in
file 2 (the SSN field) so it can be used as medical record number. Using
HRN in file 901 is much easier. It is already there.
To me there seems to be some important issues raised in the first post on
this subject
Indeed, I've taken the approach of using parser driven tools to solve
problems like this, but the problem is harder than you might think.
Consider that the FDA array and IENS string for a DBS call is set up
ahead of time and is very possibly referenced indirectly. I've seen
nodes of files set in
VistA analysis is so severely complex as to be reasonably regarded as not
computable. ...no surprise there.
However, as I said in the message quoted below, given a LIMITED SCOPE, well
specified problem, analysis at the SEMANTIC level (I am not just talking
about a parser tree crawl), is feasible
FWIW - I'm not sure if the following is functional but at one time the
underlying software functionality anticipated various patient types and
identifiers.
Check out the following files/fields in VistA to see if the
functionality to support alternate patient identifiers is supported.
Also by
I find this interesting as I am wondering if, given the restraints you suggest
be adhered to, there is any reasonable approach to the project I am working
on, Pediatrics and OBGYN for VistA, other than just creating a new bunch of
templates. I was ultimately hoping to see new Tabs in CPRS
VistA Community Call
This week:
Boston Debriefing
Defining the next OpenVistA
DATE: Friday, April 22
TIME: 12:00 Noon EDT
DURATION: 60 min. (75 available)
CONFERENCE CALL DIAL IN NUMBERS
USA 866-483-4159
Outside USA 706-634-0093
LINES AVAILABLE 21
SPECIAL INSTRUCTIONS
35 matches
Mail list logo
