--- James Gray <[EMAIL PROTECTED]> wrote:
> Standard VistA uses a X-ref on the SSN field to keep files 2 and
> 9000001 in synch. RPMS and VOE do it in a different way. They use
> an alternate look up routine on file 2 that keeps the two files in
> synch. In standard VistA, if there is no SSN there will be no entry
> in file 9000001. I cannot think of another way that standard VistA
> will result in no entry in file 9000001.
I think the cross-reference code uses ^%ZOSF("TEST") to verify that
certain routines are present before trying to call them. If they are
not, the cross-reference may "fire", but not actually do anything (but
that's standard VistA).
> 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 Record Number field of file 9000001 that violates the input
> transform of the field!
Ouch.
> 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.
> 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
