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. 
  1. BLRMERGD ;IHS/ISD/EDE - LAB MERGE DOCUMENTATION  [ 12/21/1998  3:55 PM ]
  1.  ;;5.2;BLR;**1005**;DEC 14, 1998
  1.  ;
  1.  ;LAB PATIENT MERGE
  1.  ;
  1.  ;GENERAL INFO
  1.  ;
  1.  ;The Lab package files are not FileMan compatible, nor are the
  1.  ;routines that manipulate data stored in those files.  Data is
  1.  ;inserted into files using direct sets and xrefs are generated
  1.  ;in the same manner.  Some fields have xrefs defined but they are
  1.  ;never fired because the data is not added using ^DIE.  I do not
  1.  ;know for sure but it is possible that some fields are valued using
  1.  ;FileMan calls, but others certainly are not.  Where possible 
  1.  ;the BLRMERG* routines modify data using ^DIE.  Because this will
  1.  ;trigger xrefs defined in the dictionary there may be xrefs set
  1.  ;that were not set by the hard code that originally valued the
  1.  ;fields.  Furthermore, there is no assurance that the xrefs defined
  1.  ;in the dictionary are exactly the same as the xrefs generated by
  1.  ;hard code.  Because of these inconsistencies, after the field
  1.  ;values are changed using ^DIE I modify various xrefs using hard
  1.  ;sets and kills.
  1.  ;
  1.  ;After the two lab patients are merged a bulletin, named PCC
  1.  ;LAB PATIENT MERGEIs sent to the mail group named PCC LAB PATIENT
  1.  ;MERGE.
  1.  ;
  1.  ;AFFECTED FILES
  1.  ;
  1.  ;--------------------
  1.  ;VA Patient 2, ^DPT(
  1.  ;
  1.  ;The "LR" node for a patient entry points to that patient's lab
  1.  ;data in the Lab Data file 63, 
  1.  ;^LR(, (e.g. ^DPT(222,"LR")=2).
  1.  ;
  1.  ;--------------------
  1.  ;Lab Data file 63, ^LR(
  1.  ;
  1.  ;Field .02, D0,0 is the parent file.  The VA Patient file 2 for
  1.  ;this purpose.
  1.  ;Field .03, D0,0 is the ien of the patient.
  1.  ;
  1.  ;There is one entry in this file for each Lab patient.  Within one
  1.  ;patient's entry lab tests are stored by accession area (e.g. BB,
  1.  ;CH, CY, SP).  Within these subscripts data is stored by inverse
  1.  ;date.  The 1st piece of the 0th node is the date/time the specimen
  1.  ;was taken.  The 6th piece of the 0th node provides access to the
  1.  ;associated entry in the Accession file 68, ^LRO(68,.  The format
  1.  ;of the 6th piece varies depending on the accession area.  For CY,
  1.  ;SP, EM, and AU the 6th piece is a number which is the ien in the 
  1.  ;Accession Number multiple 68.02 in the Accession file 68.  For CH,
  1.  ;BB, and MI the 6th piece is freetext in the form `aa xxxx n' where
  1.  ;aa=the type (e.g. HE for Hematology), and n=the ien in the 68.02
  1.  ;multiple.  The xxxx represents a transformation of the date the 
  1.  ;specimen was taken.  The transformation is based on the type and
  1.  ;may be daily, monthly, quarterly, or annually.
  1.  ;
  1.  ;^LR(8,"CY" 7019487,0)="2980512^607^^^CLAYTON CURTIS MD^1^17^IM etc"
  1.  ;^LR(9,"BB",7019492.869244,0)="2980506.130756^^2980506.1325^^70^BB 0506 1^ 
  1.  ;etc"
  1.  ;--------------------
  1.  ;Accession file 68, ^LRO(68,
  1.  ;
  1.  ;Data is stored in this file by accession area, and within accession
  1.  ;area by date, and within that by entry within that date.  The 1st
  1.  ;piece of the 0th node of each entry is the LRDFN which is a pointer
  1.  ;to the patient's entry in the Lab Data file 63, ^LR(.
  1.  ;
  1.  ;--------------------
  1.  ;Lab Order Entry file 69, ^LRO(69,
  1.  ;
  1.  ;Data is stored in this file by date ordered, and within date ordered
  1.  ;by sequence number.  The 1st piece of the 0th node is the LRDFN
  1.  ;which is a pointer to the patient's entry in the Lab Data file 63,
  1.  ;^LR(
  1.  ;
  1.  ;
  1.  ;MERGE LOGIC/NAVIGATION
  1.  ;
  1.  ;General:
  1.  ;
  1.  ;All entries in the Lab Order Entry file 69 that point to the Lab
  1.  ;Data file 63 entry for the `from' patient are repointed to the
  1.  ;`to' patient.  All entries in the Accession file 68 that point
  1.  ;to the Lab Data file 63 entry for the `from' patient are repointed
  1.  ;to the `to' patient. The `from' patient's entry in the Lab Data
  1.  ;file 63 is copied into the `to' patient's entry in the Lab Data
  1.  ;file 63 and the `from' patient's entry is deleted.
  1.  ;
  1.  ;Detail:
  1.  ;
  1.  ;When two patients are merged in the VA PATIENT file, # 2, ^DPT(
  1.  ;the "LR" node for each patient is checked to see if they have an
  1.  ;entry in the lab system.  The "LR" node contains a pointer to that
  1.  ;patient's entry in the LAB DATA file, # 63, ^LR(.  I will 
  1.  ;subsequently refer to this pointer as LRDFN.  All lab data for
  1.  ;that patient is stored in ^LR(LRDFN,.  Data is stored in file 63
  1.  ;by accession area within LRDFN, and generally by inverse date
  1.  ;within accession area.  E.g., ^LR(LRDFN,"CH",7019479.895049, etc.
  1.  ;The exception to that is autopsy which is stored by subscripts
  1.  ;".1", "AU", "AV", "AW", and "AWI".
  1.  ;
  1.  ;If the `to' patient has data in file 63 but the `from' patient
  1.  ;does not, then no action is necessary.
  1.  ;
  1.  ;If the `from' patient has data in file 63 but the `to' patient
  1.  ;does not, then all that is needed is to set the "LR" node for the
  1.  ;`to' patient to the LRDFN of the `from' patient, change the 
  1.  ;patient pointer in the ^LR(LRDFN entry to point to the `to'
  1.  ;patient instead of the `from' patient, and kill the "LR" node
  1.  ;on the `from' patient.
  1.  ;
  1.  ;When both the `from' and `to' patients have data in file 63 then
  1.  ;the `from' patient's data must be merged with the `to' patient's
  1.  ;data.  This will result in the `from' patient's ^LR entry being
  1.  ;deleted.  There are other lab files that point to this ^LR entry,
  1.  ;therefore, the fields in those files must be repointed prior to
  1.  ;the file 63 merge.
  1.  ;
  1.  ;This is accomplished in two different ways.  The first approach
  1.  ;is to follow a link field in file 63 to an entry in the ACCESSION
  1.  ;file, # 68, ^LRO(68,.  The link field is stored in the 6th piece
  1.  ;of the 0th node of each accession area in file 63, e.g. 
  1.  ;^LR(LRDFN,"CH",inverse date,0) or ^LR(LRDFN, "AU") for autposy.
  1.  ;
  1.  ;The format of the link field varies depending on the accession
  1.  ;area.  For CY, SP, EM, and AU the link field is a number which
  1.  ;is the ien in the Accession Number multiple 68.02 in the Accession
  1.  ;file 68.  For CH, BB, and MI the link field is freetext in the form 
  1.  ;`aa xxxx n' where aa=the type (e.g. HE for Hematology), and n=the
  1.  ;ien in the 68.02 multiple.  The xxxx is a transformation of the
  1.  ;date and not used by the merge software.
  1.  ;
  1.  ;Data is stored in the ACCESSION file, # 68, by date within
  1.  ;accession area.  That means that all BLOOD BANK entries are stored
  1.  ;under the ien for BLOOD BANK, and within that by accession date,
  1.  ;and within that by accession number for that area/date, e.g. 
  1.  ;^LRO(68,4,1,2980519,1,2,0) which would be the 2nd accession number
  1.  ;for 2980519 for accession area ien 4, which happens to be BLOOD
  1.  ;BANK.  The .01 field of the 68.02 multiple is a pointer to file 63,
  1.  ;^LR(LRDFN which corresponds to a particular patient.  
  1.  ;This field is changed to point to the `to' patient's ^LR( entry
  1.  ;instead of the `from' patient's ^LR( entry.
  1.  ;
  1.  ;In the ACCESSIONS file, # 68 BB, CH, etc. entries are stored by
  1.  ;a transformation of the 
  1.  ;date, based on whether the accession numbers roll over daily,
  1.  ;monthly, quarterly, etc., for the D1 subscript but CY, SP, etc.
  1.  ;are stored by cyy0000 instead.  The "C" xref in the Lab Order file
  1.  ;69 is by the normal date for CY, SP etc.
  1.  ;
  1.  ;For some accession areas there is a link in file 68 to the LAB
  1.  ;ORDER ENTRY file, # 69, ^LRO(69,.  When it exists this link pointer
  1.  ;is stored as the .1 node in file 63.  E.g.,
  1.  ;^LRO(68,4,1,2980519,1,2,.1)=4.
  1.  ;
  1.  ;Data is stored in the LAB ORDER ENTRY file, # 69, by date ordered,
  1.  ;and within that by sequence #.  These entries are located via the
  1.  ;"C" xref  which is in the following form:
  1.  ;^LRO(69,"C",order #,date ordered,sequence #)="".  The .01 field
  1.  ;of the 69.01 multiple is a pointer to file 63, ^LR(LRDFN which
  1.  ;corresponds to a particular patient.  This field is changed to
  1.  ;point to the `to' patient's ^LR( entry instead of the `from'
  1.  ;patient's ^LR( entry.
  1.  ;
  1.  ;Prior to repointing the 69.01 .01 field the kill side of the
  1.  ;xrefs on 69.01 21 and 69.03 .01 are executed and then the set
  1.  ;side of the xrefs are executed after the repointing of 69.01 .01.
  1.  ; 
  1.  ;Also after the 69.01 .01 field is repointed the "AN" xrefs are
  1.  ;modified.  One "AN" xref is at the file level, ^LRO(69,"AN", and
  1.  ;the other is at a multiple level, ^LRO(69,date,1,"AN".
  1.  ;
  1.  ;Because following the link fields does not find all relevant
  1.  ;entries the second approach is to find associated entries in file
  1.  ;69 using the "D" xref which is in the form 
  1.  ;^LRO(69,"D",'from' patient's LRDFN,date,specimen #)="".  The same
  1.  ;action as discussed above for file 69 is executed for entries found
  1.  ;via the "D" xref.
  1.  ;
  1.  ;Additionally, the "AC" xref and the "MI" xref are reset to use the
  1.  ;`to' patient's LRDFN.  They are in the form
  1.  ;^LRO(68,"AC",'from' patient's LRDFN,date,accession #)="" and 
  1.  ;the same form for "MI".  The xrefs are fixed using hard sets.
  1.  ;
  1.  ;After fields in files 68 and 69 are repointed the `from' patient's
  1.  ;^LR entry is merged into the `to' patient's ^LR entry.  ^LR
  1.  ;entries are stored by inverse date within accession area so no
  1.  ;`from' patient entry can have the same inverse date as any `to'
  1.  ;patient entry within the same accession area.  To resolve this
  1.  ;problem each `from' patient entry is checked to see if the `to'
  1.  ;patient has the same entry.  If the `to' patient does have the
  1.  ;same entry then the date/time of the `from' patient's entry is
  1.  ;incremented by one second and checked again.  This process
  1.  ;continues until an unused inverse date slot is found.  Then the 
  1.  ;date/time is changed in files 68 and 69 and in the ^LR entry, the
  1.  ;changed ^LR entry is copied to the new inverse date slot in the
  1.  ;`from' patients ^LR entry, and the old inverse date entry is
  1.  ;deleted.  After all `from' and `to' patient inverse date entries
  1.  ;are unique the `from' patient's ^LR entry is copied to the `to'
  1.  ;patient's ^LR entry and then the `from' patient's ^LR entry is
  1.  ;deleted.  After the copy the `to' patient's ^LR entry in re-indexed.