I just added some of the answer about the Broker to the CPRS installation
section on the wiki. I found if I previewed what I edited, it disappeared
when I went back to edit, but if I just did the edit and saved it, it worked
fine. Has anyone else had a similar experience? I am using Mozilla
Nancy Anthracite wrote:
I just added some of the answer about the Broker to the CPRS installation
section on the wiki. I found if I previewed what I edited, it disappeared
when I went back to edit, but if I just did the edit and saved it, it worked
fine. Has anyone else had a similar
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Wednesday, January 11, 2006 9:48 AM
Subject: Re: [Hardhats-members] Re: Mysterious intermitant problem...
--- James Gray [EMAIL PROTECTED] wrote:
In my humble opinion the
--- James Gray [EMAIL PROTECTED] wrote:
Actually when people try to do imports of patient registration data
from
another system into VistA they are doing something that is
essentially
editing by hand.
Of course. But does having noble intentions make the process work any better?
===
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
--- James Gray [EMAIL PROTECTED] wrote:
Actually when people try to do imports of patient registration data
from
another system into VistA they are doing something that is
essentially
editing by hand.
Of course. But
--- James Gray [EMAIL PROTECTED] wrote:
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
--- James Gray [EMAIL PROTECTED] wrote:
Actually when people try to do imports of patient registration
data
from
another system into VistA they are doing something
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
--- James Gray [EMAIL PROTECTED] wrote:
No, and it seems that Kevin ran into a problem with his import. My
main
point is that this is not really something that you should never
do. It
does sound like that when people
I am the principal of a seed stage venture fund in
New York City. We are interested in projects involving vistA andthe
migration of global medical systems to electronic record keeping
andbilling. We are also interestedprojects whichuse the
data produced fornew analytic products.
We are
You all know what I think of this.
http://www.ihealthbeat.org/index.cfm?Action=dspItemitemID=118019
--
Nancy Anthracite
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
--- Nancy Anthracite [EMAIL PROTECTED] wrote:
You all know what I think of this.
http://www.ihealthbeat.org/index.cfm?Action=dspItemitemID=118019
--
Nancy Anthracite
Have you noticed that the New York Times is running a four part article
on diabetes on its front page this week? It makes
Does this affect any VA's? If so, will they comply?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nancy
Anthracite
Sent: Wednesday, January 11, 2006 1:07 PM
To: hardhats-members@lists.sourceforge.net
Subject: [Hardhats-members] More information about
Hopefully, since they are federal, it won't. If it does, I hope the VA
lawyers will fight it HARD.
In the Washington Post article I just read in todays paper, medical testing
laboratories with the ability to transmit data electronically will be
required to report the results, which sends
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
--- James Gray [EMAIL PROTECTED] wrote:
Standard VistA uses a lookup routine on file 2. What do you
recommend as an
alternative to the lookup routines used by VistA, RPMS, and VOE to
create
the functionality those
On 1/11/06, James Gray [EMAIL PROTECTED] wrote:
Standard VistA uses a lookup routine on file 2.What do you recommend as analternative to the lookup routines used by VistA, RPMS, and VOE to createthe functionality those lookup routines provide?Jim
A different be related question is how SHOULD I
This is an old topic--perhaps. I have a collegue hand me a magazine with yet another review of VistAOffice, and brought up the tired arguments about how the supposedly free VistAOffice was going to have hidden charges such as Cache' licensing.
So why doesn't CMS end-run these arguments by just
Does anyone else get this:
The FTP server 215 MSDOS A N (FTPServer V4R2 by BisonWare
International) is currently unsupported.
when trying to access these diagrams??
And would anyone be interested in having a full set of
diagrams? I'm guessing that they could prove useful in the
event that
The Bisonware thing can be a problem on any platform other than IE, so you can
do it with the command line, or with another product (I use gftp on Linux),
but to save you the trouble, I will send you instructions for how to get them
off my server.
On Wednesday 11 January 2006 02:53 pm, Stephen
Kevin,
You should have thePX09 X-ref on the .09
field of file 2. That X-ref should be fired when you add a new SSN when
adding a new patient. That should add a new entry into file 901.
If the patient you areautomatically registering has a SSN you should be
getting an entry in the IHS
What sort of tool do you have, a diagraming tool or some sort of code that
does this mapping for VistA? I don't know much about UML.
I wonder if the VA has already done it and if it might be available for the
asking.
On Wednesday 11 January 2006 02:53 pm, Stephen Hay wrote:
Does anyone else
Re-wording the subject line
Manual entry is the usual means of
registration. What youre describing is automated entry using a silent
API. This problem sounds like a bug that should be corrected in Registration
code in the course of supporting VOE. There should be a cross-reference on
Unfortunately, our billing software has only pre-defined, canned reports that it will do. And for some reason it doesn't include SSNum on the report. We then use this deficent report to bring data into VistA.
I guess I could create my own entries in 901, just like I did last night to fix my
Thanks Cameron.Let me clarify that when I use the VistA manual registration methods (i.e. a user inputs the data by hand), it works fine. But then I think I always specify a ssnum, or a pseudossnum. Maybe that is the key.
KevinOn 1/11/06, Cameron Schlehuber [EMAIL PROTECTED] wrote:
--- James Gray [EMAIL PROTECTED] wrote:
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
If you want to ensure that
certain conditions hold or that a particular action is taken when a
record is *added*, then the use of a special lookup is
inappropriate.
I do not
The main reason is that the CMS folks
considered it simplest to have clinics need only one OS, the Windows platform
(since the CPRS GUI currently only operates on that OS). Also, for the second
environment the instructions for installation and setup would need to cover two
platforms rather
Those diagrams were generated automatically from Fileman (ultimately
using the SQLI library) using a tool known as ERwin. Other approaches
are possible, too. for example, many tools support reverse engineering
of ODBC data sources. But I think you will find that, at some point,
you're going to
Kevin wrote: "And for some reason it doesn't include SSNum on the
report."
And why should it? There is really no reason why
someone's SSN should be on their medical forms nor should it be used as a
database key by anyone except the IRS. (just one of my pet
peeves).
tjh
From:
[EMAIL
Yes, this happens if you don't use IE for that site.
Stephen Hay wrote:
Does anyone else get this:
The FTP server 215 MSDOS A N (FTPServer V4R2 by BisonWare
International) is currently unsupported.
when trying to access these diagrams??
And would anyone be interested in having a full set
I just received the Jan. 2006 issue of Communication of the ACM (vol.
49, no. 1). There's an article, Personal Health Information
Management that may be of interest to the group:
Personal Information Management (PIM) pervades every aspect of our
lives, including health care. As users of the
Since the data looks the same, I'd look for some code in the dictionary
of file 8925 that might be blocking the pointer resolution or perhaps
something in file 2's DD.
Kevin Toppenberg wrote:
We have a physician that is leaving our group, and he wants to have a
copy of the notes he wrote
That brings up the topic of personal heatlh records, which was the subject
considered by an AMIA committee. I sat in on a presentation about their
work. It is, as is so often the case, something that needs some standards.
There is nothing standard about what patients can access to make these
As was just pointed out by someone else,
its the x-ref on the SSN field .09 that does the creation of parallel
entries in file 9001 and NOT in the DPTLK routines as I mistakenly
thought. Its that x-ref that should really be on the PRIMARY LONG
ID field .363.
-Original
Press release is here
http://www.medsphere.com/media/press/20060109-1.rbw
--
Nancy Anthracite
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that
Here at our CHC we occasionally get undocumented
patients, meaning they dont have a SSN. Will this cause a problem when
we start using VistA?
Matthew M. King, MD
Medical Director
Clinica Adelante, Inc
Surprise, Arizona 85374
[EMAIL PROTECTED]
-Original Message-
From:
Nancy:
The traditional fragmented efforts may be coming to an end. The new ANSI
HITSP is charged with coordinating the use and development of appropriate
EHR standards. Many of these exist and have much common ground - if
anybody pays attention to them. Interestingly I just spoke with Richard
If the data you are using does not include SSN,
then it would probably be best if you include code that always creates the stub
entry in 901 at exactly the same IEN. Anyone who is importing patient
registrationdata into standard VistA will need to do that if their data
does not include
Kevin,
That is the key. As long as you specify a
value for the .09 field you are fine and will get an entry in file
901.
Jim
- Original Message -
From:
Kevin Toppenberg
To: hardhats-members@lists.sourceforge.net
Sent: Wednesday, January 11, 2006 1:29
PM
Where does the HL7 group and the CCHIT and ONCHIT fit into all of this?
On Wednesday 11 January 2006 04:52 pm, A. Forrey wrote:
Nancy:
The traditional fragmented efforts may be coming to an end. The new ANSI
HITSP is charged with coordinating the use and development of appropriate
EHR standards.
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
Questions like this always provoke controversy. After all, you might
ask, what right does this Greg Woodhouse guy have to say that such and
such a programming practice is a bad idea? What IS a bad idea? We all
have our own
Thanks Jim,That's very helpful information.KevinOn 1/11/06, James Gray [EMAIL PROTECTED] wrote:
If the data you are using does not include SSN,
then it would probably be best if you include code that always creates the stub
entry in 901 at exactly the same IEN. Anyone who is importing
I mentioned this earlier, but I have completed what I think is a cool project.My function takes a search/sort template that contains a list of record numbers (as would be generated by a fileman search etc.) in the TIU DOCUMENT file (
i.e. progress notes etc.). I then creates a website of all these
--- James Gray [EMAIL PROTECTED] wrote:
Greg, Please do not be concerned about provoking controversy because
of my
questions. ...
I guess I was concerned because others have taken offense at comments
or questions I've posted to the list (even when they were intended to
be nothing more than
So this is the start of the patient interface for VistA, correct?
On Wednesday 11 January 2006 05:26 pm, Kevin Toppenberg wrote:
I mentioned this earlier, but I have completed what I think is a cool
project.
My function takes a search/sort template that contains a list of record
numbers (as would
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
--- James Gray [EMAIL PROTECTED] wrote:
Greg, Please do not be concerned about provoking controversy because
of my
questions. ...
I guess I was concerned because others have taken offense at comments
or questions I've
On Wed, 11 Jan 2006, Nancy Anthracite wrote:
Where does the HL7 group and the CCHIT and ONCHIT fit into all of this?
HL7 is an SDO member of HITSP. HITSP, AHIC and CCHIT are contracted
projects sponsored by ONCHIT which is directed by Sec HHS and the
President to set up a mechanism by
Gregory wrote:
--- James Gray [EMAIL PROTECTED] wrote:
One of the advantages to
the way RPMS and VOE do it is that SSN can be optional and you still
get entries in both files. I will add two more comments. Standard
VistA does it synchronization by stuffing a value (the SSN) into the
Health
James,
Do you know if the new Patient lookup makes use of the silent DBS API's or if
it is tied
to the old CHUI (telnet) interface?
I am building a web based patient registration and the next major step is make
the patient
lookup work properly and to create new patient records from that. I have
http://www.whitedust.net/article/45/Future_Trends_of_Malware/
I haven't read all of it yet, but I have bookmarked it and will be
reading it over the next several days. It's clear that the author has
much to say, and the flow is a little rough, but there is much there to
ponder for those of us
Jim,
The new patient lookup used in VOE is basically the same as the lookup
routine used by IHS. It starts at ^AUPNLK. Actually VOE seems to use
^DPTLK, but if you look inside it goes to ^AUPNLK. It uses lots of classic
fileman calls. Note that the version of ^AUPN routines you get with a
Kevin,
The essential problem is the same whether importing patient records from
another system or
entering them from a web interface or GUI. A solution for one could be 9/10 of
a solution
for the others if the basic functionality of looking up and creating patient
records is
encapsulated in an
Cameron wrote:
Manual entry is the usual means of registration. What you're describing is
automated entry using a silent API. This problem sounds like a bug that
should be corrected in Registration code in the course of supporting VOE.
Definitely. :) This bug (the lack of silent API's for
James Gray [EMAIL PROTECTED] wrote:
- Original Message -
From: Greg Woodhouse [EMAIL PROTECTED]
Any logic tucked away in a special lookup routine will not be honored
by the silent calls. That's expected because the lookup routines are
used to provide a user interface (comparable to
Many vendors are putting a lot of resources to prepare to support the
windows-based VistA-Office EHR. Before it's too late, it would be
great to know whether there are plans for a GT.M-based release in the
near future. According to our actual and potential customers a version
with no hidden
I would say it is a virtual guarantee that if VOE is released, a GTM port will
soon follow. However, it has to get released first.
On Wednesday 11 January 2006 08:26 pm, Max Mansoubi wrote:
Many vendors are putting a lot of resources to prepare to support the
windows-based VistA-Office EHR.
VA too must be able to register the
occasional patient who has no readily available SSN. VistA as currently implemented
in VA supports the use of pseudo-SSNs (the values are calculated based on other
identifying traits for the patient, such as birth date.) Future patches
to VistA in
And I would add that the soon would be on the order of days if not hours.
Moving the routines and globals for VistA (the sum total of all that there
is to the VistA-M side of things) from Cache to GT.M (or vice versa) is
quite straight-forward. The infrastructure components of VistA run on both
- Original Message -
From: Jim Self [EMAIL PROTECTED]
James Gray [EMAIL PROTECTED] wrote:
Standard VistA uses a lookup routine on file 2. What do you recommend as
an
alternative to the lookup routines used by VistA, RPMS, and VOE to create
the functionality those lookup
Thanks to all who responded.
I've managed to download the diagrams and, yes, they
certainly look as though they were generated automatically...
So, to answer some of the questions.
I use a tool called Mega Suite from www.mega.com which is
widely regarded as best of breed for process
57 matches
Mail list logo
