Home   Package List   Routine Alphabetical List   Global Alphabetical List   FileMan Files List   FileMan Sub-Files List   Package Component Lists   Package-Namespace Mapping  
Routine: BLRMERGD

BLRMERGD.m

Go to the documentation of this file. 
BLRMERGD ;IHS/ISD/EDE - LAB MERGE DOCUMENTATION  [ 12/21/1998  3:55 PM ]

 ;;5.2;BLR;**1005**;DEC 14, 1998

 ;

 ;LAB PATIENT MERGE

 ;

 ;GENERAL INFO

 ;

 ;The Lab package files are not FileMan compatible, nor are the

 ;routines that manipulate data stored in those files.  Data is

 ;inserted into files using direct sets and xrefs are generated

 ;in the same manner.  Some fields have xrefs defined but they are

 ;never fired because the data is not added using ^DIE.  I do not

 ;know for sure but it is possible that some fields are valued using

 ;FileMan calls, but others certainly are not.  Where possible 

 ;the BLRMERG* routines modify data using ^DIE.  Because this will

 ;trigger xrefs defined in the dictionary there may be xrefs set

 ;that were not set by the hard code that originally valued the

 ;fields.  Furthermore, there is no assurance that the xrefs defined

 ;in the dictionary are exactly the same as the xrefs generated by

 ;hard code.  Because of these inconsistencies, after the field

 ;values are changed using ^DIE I modify various xrefs using hard

 ;sets and kills.

 ;

 ;After the two lab patients are merged a bulletin, named PCC

 ;LAB PATIENT MERGEIs sent to the mail group named PCC LAB PATIENT

 ;MERGE.

 ;

 ;AFFECTED FILES

 ;

 ;--------------------

 ;VA Patient 2, ^DPT(

 ;

 ;The "LR" node for a patient entry points to that patient's lab

 ;data in the Lab Data file 63, 

 ;^LR(, (e.g. ^DPT(222,"LR")=2).

 ;

 ;--------------------

 ;Lab Data file 63, ^LR(

 ;

 ;Field .02, D0,0 is the parent file.  The VA Patient file 2 for

 ;this purpose.

 ;Field .03, D0,0 is the ien of the patient.

 ;

 ;There is one entry in this file for each Lab patient.  Within one

 ;patient's entry lab tests are stored by accession area (e.g. BB,

 ;CH, CY, SP).  Within these subscripts data is stored by inverse

 ;date.  The 1st piece of the 0th node is the date/time the specimen

 ;was taken.  The 6th piece of the 0th node provides access to the

 ;associated entry in the Accession file 68, ^LRO(68,.  The format

 ;of the 6th piece varies depending on the accession area.  For CY,

 ;SP, EM, and AU the 6th piece is a number which is the ien in the 

 ;Accession Number multiple 68.02 in the Accession file 68.  For CH,

 ;BB, and MI the 6th piece is freetext in the form `aa xxxx n' where

 ;aa=the type (e.g. HE for Hematology), and n=the ien in the 68.02

 ;multiple.  The xxxx represents a transformation of the date the 

 ;specimen was taken.  The transformation is based on the type and

 ;may be daily, monthly, quarterly, or annually.

 ;

 ;^LR(8,"CY" 7019487,0)="2980512^607^^^CLAYTON CURTIS MD^1^17^IM etc"

 ;^LR(9,"BB",7019492.869244,0)="2980506.130756^^2980506.1325^^70^BB 0506 1^ 

 ;etc"

 ;--------------------

 ;Accession file 68, ^LRO(68,

 ;

 ;Data is stored in this file by accession area, and within accession

 ;area by date, and within that by entry within that date.  The 1st

 ;piece of the 0th node of each entry is the LRDFN which is a pointer

 ;to the patient's entry in the Lab Data file 63, ^LR(.

 ;

 ;--------------------

 ;Lab Order Entry file 69, ^LRO(69,

 ;

 ;Data is stored in this file by date ordered, and within date ordered

 ;by sequence number.  The 1st piece of the 0th node is the LRDFN

 ;which is a pointer to the patient's entry in the Lab Data file 63,

 ;^LR(

 ;

 ;

 ;MERGE LOGIC/NAVIGATION

 ;

 ;General:

 ;

 ;All entries in the Lab Order Entry file 69 that point to the Lab

 ;Data file 63 entry for the `from' patient are repointed to the

 ;`to' patient.  All entries in the Accession file 68 that point

 ;to the Lab Data file 63 entry for the `from' patient are repointed

 ;to the `to' patient. The `from' patient's entry in the Lab Data

 ;file 63 is copied into the `to' patient's entry in the Lab Data

 ;file 63 and the `from' patient's entry is deleted.

 ;

 ;Detail:

 ;

 ;When two patients are merged in the VA PATIENT file, # 2, ^DPT(

 ;the "LR" node for each patient is checked to see if they have an

 ;entry in the lab system.  The "LR" node contains a pointer to that

 ;patient's entry in the LAB DATA file, # 63, ^LR(.  I will 

 ;subsequently refer to this pointer as LRDFN.  All lab data for

 ;that patient is stored in ^LR(LRDFN,.  Data is stored in file 63

 ;by accession area within LRDFN, and generally by inverse date

 ;within accession area.  E.g., ^LR(LRDFN,"CH",7019479.895049, etc.

 ;The exception to that is autopsy which is stored by subscripts

 ;".1", "AU", "AV", "AW", and "AWI".

 ;

 ;If the `to' patient has data in file 63 but the `from' patient

 ;does not, then no action is necessary.

 ;

 ;If the `from' patient has data in file 63 but the `to' patient

 ;does not, then all that is needed is to set the "LR" node for the

 ;`to' patient to the LRDFN of the `from' patient, change the 

 ;patient pointer in the ^LR(LRDFN entry to point to the `to'

 ;patient instead of the `from' patient, and kill the "LR" node

 ;on the `from' patient.

 ;

 ;When both the `from' and `to' patients have data in file 63 then

 ;the `from' patient's data must be merged with the `to' patient's

 ;data.  This will result in the `from' patient's ^LR entry being

 ;deleted.  There are other lab files that point to this ^LR entry,

 ;therefore, the fields in those files must be repointed prior to

 ;the file 63 merge.

 ;

 ;This is accomplished in two different ways.  The first approach

 ;is to follow a link field in file 63 to an entry in the ACCESSION

 ;file, # 68, ^LRO(68,.  The link field is stored in the 6th piece

 ;of the 0th node of each accession area in file 63, e.g. 

 ;^LR(LRDFN,"CH",inverse date,0) or ^LR(LRDFN, "AU") for autposy.

 ;

 ;The format of the link field varies depending on the accession

 ;area.  For CY, SP, EM, and AU the link field is a number which

 ;is the ien in the Accession Number multiple 68.02 in the Accession

 ;file 68.  For CH, BB, and MI the link field is freetext in the form 

 ;`aa xxxx n' where aa=the type (e.g. HE for Hematology), and n=the

 ;ien in the 68.02 multiple.  The xxxx is a transformation of the

 ;date and not used by the merge software.

 ;

 ;Data is stored in the ACCESSION file, # 68, by date within

 ;accession area.  That means that all BLOOD BANK entries are stored

 ;under the ien for BLOOD BANK, and within that by accession date,

 ;and within that by accession number for that area/date, e.g. 

 ;^LRO(68,4,1,2980519,1,2,0) which would be the 2nd accession number

 ;for 2980519 for accession area ien 4, which happens to be BLOOD

 ;BANK.  The .01 field of the 68.02 multiple is a pointer to file 63,

 ;^LR(LRDFN which corresponds to a particular patient.  

 ;This field is changed to point to the `to' patient's ^LR( entry

 ;instead of the `from' patient's ^LR( entry.

 ;

 ;In the ACCESSIONS file, # 68 BB, CH, etc. entries are stored by

 ;a transformation of the 

 ;date, based on whether the accession numbers roll over daily,

 ;monthly, quarterly, etc., for the D1 subscript but CY, SP, etc.

 ;are stored by cyy0000 instead.  The "C" xref in the Lab Order file

 ;69 is by the normal date for CY, SP etc.

 ;

 ;For some accession areas there is a link in file 68 to the LAB

 ;ORDER ENTRY file, # 69, ^LRO(69,.  When it exists this link pointer

 ;is stored as the .1 node in file 63.  E.g.,

 ;^LRO(68,4,1,2980519,1,2,.1)=4.

 ;

 ;Data is stored in the LAB ORDER ENTRY file, # 69, by date ordered,

 ;and within that by sequence #.  These entries are located via the

 ;"C" xref  which is in the following form:

 ;^LRO(69,"C",order #,date ordered,sequence #)="".  The .01 field

 ;of the 69.01 multiple is a pointer to file 63, ^LR(LRDFN which

 ;corresponds to a particular patient.  This field is changed to

 ;point to the `to' patient's ^LR( entry instead of the `from'

 ;patient's ^LR( entry.

 ;

 ;Prior to repointing the 69.01 .01 field the kill side of the

 ;xrefs on 69.01 21 and 69.03 .01 are executed and then the set

 ;side of the xrefs are executed after the repointing of 69.01 .01.

 ; 

 ;Also after the 69.01 .01 field is repointed the "AN" xrefs are

 ;modified.  One "AN" xref is at the file level, ^LRO(69,"AN", and

 ;the other is at a multiple level, ^LRO(69,date,1,"AN".

 ;

 ;Because following the link fields does not find all relevant

 ;entries the second approach is to find associated entries in file

 ;69 using the "D" xref which is in the form 

 ;^LRO(69,"D",'from' patient's LRDFN,date,specimen #)="".  The same

 ;action as discussed above for file 69 is executed for entries found

 ;via the "D" xref.

 ;

 ;Additionally, the "AC" xref and the "MI" xref are reset to use the

 ;`to' patient's LRDFN.  They are in the form

 ;^LRO(68,"AC",'from' patient's LRDFN,date,accession #)="" and 

 ;the same form for "MI".  The xrefs are fixed using hard sets.

 ;

 ;After fields in files 68 and 69 are repointed the `from' patient's

 ;^LR entry is merged into the `to' patient's ^LR entry.  ^LR

 ;entries are stored by inverse date within accession area so no

 ;`from' patient entry can have the same inverse date as any `to'

 ;patient entry within the same accession area.  To resolve this

 ;problem each `from' patient entry is checked to see if the `to'

 ;patient has the same entry.  If the `to' patient does have the

 ;same entry then the date/time of the `from' patient's entry is

 ;incremented by one second and checked again.  This process

 ;continues until an unused inverse date slot is found.  Then the 

 ;date/time is changed in files 68 and 69 and in the ^LR entry, the

 ;changed ^LR entry is copied to the new inverse date slot in the

 ;`from' patients ^LR entry, and the old inverse date entry is

 ;deleted.  After all `from' and `to' patient inverse date entries

 ;are unique the `from' patient's ^LR entry is copied to the `to'

 ;patient's ^LR entry and then the `from' patient's ^LR entry is

 ;deleted.  After the copy the `to' patient's ^LR entry in re-indexed.