----- Original Message ----- From: "Greg Woodhouse" <[EMAIL PROTECTED]>
To: <[email protected]>
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 way RPMS and VOE do
it is better.  This is a potential gotcha for adopters who want to
make the SSN field optional.

Special lookup routines have their own problems, too. For one they
restrict you to Classic Fileman. For File 2, that's probably okay,
because no one should be editing this file "by hand", anyway, but it's
an ugly solution.

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.

Jim Gray
----- Original Message ----- From: Kevin Toppenberg
  To: Hardhats Sourceforge
  Sent: Tuesday, January 10, 2006 10:48 PM
  Subject: [Hardhats-members] Re: Mysterious intermitant problem...


  Well, I have this fixed.

  For every entry in file 2 that did not have an entry in file
9000001, I created two entries:
  ^AUPNPAT(ien,0)=ien
  and
  ^AUPNPAT("B",ien,ien)=""

  And now it all seems to work properly.  I've backed up the ^AUPNPAT
global for awhile incase I have introduced some unforseen error.

  Now to bed! (12:47am here!)

  Kevin



  On 1/11/06, Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
    I have 67862 entries in my PATIENT file with no corresponding
entry in the PATIENT/IHS file.  And I have 2916 entries that DO have
a corresponding match.

    This sound suspiciously like the number of patients I manually
imported from my old database.  And the 2916 would be the number of
patients added since using the proper registration menu options.

    Now, how to fix the problem without causing more problems...

    Kevin




    On 1/11/06, Kevin Toppenberg < [EMAIL PROTECTED]> wrote:
      Well, I have come up with some clues.

      First, the PATIENT (.02) field of 8925 (TIU DOCUMENT) is not a
pointer to the PATIENT file, but instead points to 9000001 file
(PATIENT/IHS), which in turn points to the PATIENT file.

      For the missing entries, I have a corresponding gap in my
PATIENT/IHS file.  This prevents a connection back to the PATIENT
file, and consequently to the patient name.

      So I need to figure out why some patients are in the database
without enteries in the PATIENT/IHS file (and how to fix this).

      Also, I think that some of the VistA code short-circuits this
loop, because the patient name WILL show up in certain places, but
not others.

      Any input would be appreciated.

      Thanks
      Kevin




      On 1/10/06, Kevin Toppenberg <[EMAIL PROTECTED] > wrote:
        We have a physician that is leaving our group, and he wants
to have a copy of the notes he wrote exported from VistA.  So I
thought it would be cool to try out a project I have had in my mind
for awhile, namely create an interlinked HTML version of all his
notes.  That way he doesn't have to install VistA at his new site,
and browsing the notes is as easy as using a web browser.

        Well, I have written the code that writes a progress note out
to HTML.  No problem there.

        But the problem I am having is that the patient's name is not
coming out of fileman in about 1 of 20 times.

        Here is code to show this.  I have to overwrite the actual
names with fake data.  But trust me that only the names have been
changed to protect the innocent.

        GTM>for i=1000:10:2000 write
i,"-->",$$GET1^DIQ(8925,i_",",.02),!
        1200-->john,doe
        1210-->john,doe
        1220-->john,doe
        1230-->john,doe
        1240-->john,doe
        1250-->john,doe
        1260-->
        1270-->
        1280-->john,doe
        1290-->john,doe
        1300-->john,doe
        1310-->john,doe
        1320-->john,doe
        1330-->
        1340-->
        1350-->john,doe
        1360-->john,doe
        1370-->john,doe
        1380-->john,doe
        1390-->john,doe
        1400-->john,doe
        1410-->john,doe
        1420-->
        1430-->john,doe
        1440-->john,doe
        1450-->
        1460-->
        1470-->john,doe
        1480-->john,doe
        1490-->john,doe
        1500-->
        1510-->john,doe


        Notice that several of these have NO patient name output.  In
fact of my progress notes IEN 1-5000, I can find that there are 188
such null entries.

        Is this simply because this data is not stored in the
database?  No!

        GTM>w ^TIU(8925,1450,0)    <---------- looking at IEN 1450,
that didn't show up above.
        1305^18177^^^7^^3031022^3031022^^9   <--------------- 2nd
piece is patient IEN

        GTM>w ^DPT(18177,0)
        DOE,JANE^F^2840203^^^^^^^^^^^^^^^^^1   <----------- patient
name is there (I changed to jane doe)

        GTM>w ^TIU(8925,1470,0)  <-------------- looking at IEN 1470,
that DID show up above
        1305^3111^^^7^^3030915^3030915^^50
        GTM>w ^DPT(3111,0)
        PICKELL,MARY M^F^2331019^^^^^^415541420^^^^^^^^^^^1
<-------------- patient name seems the same (I changed name)


        What is going on here?  I can't see any difference in the
data between those that show up and those that don't.  When I do a
Fileman inquire to the record, on the non-showing-up notes ( i.e.
#1450), it just prints out the IEN.  But on the normal notes (i.e.
#1470), it prints out the patient name.

        Any ideas?

        Thanks
        Kevin










===
Gregory Woodhouse  <[EMAIL PROTECTED]>
"If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases."
--Guy L. Steele, Jr.


-------------------------------------------------------
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 makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members



-------------------------------------------------------
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 makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to