PATIENT File HL7 Triggers

Re: [Hardhats] Re: How to trigger an ADT message upon "Admit a patient" in VistA?
Jason,
One component to recognize is that
1) VistA is capable of Object-Oriented "messaging" and "events" through the protocol unwinder.
2) a Protocol provides a "hook" similar to a call-back in other object oriented systems to allow your
own code to be run if you properly subscribe to the event.
3) a Trigger is a data dictionary hook that allows your code to be run when a change occurs to a data value for an entry in the file.  This is a standard FileMan process.
4) There are certain fields, especially in the PATIENT File #2 that have trigger code which call the protocol unwinder to "fire" an event.

There are many examples of this in the PATIENT File #2, Here is the DATE OF BIRTH Field #.03

Select OPTION:    DATA DICTIONARY UTILITIES
Select DATA DICTIONARY UTILITY OPTION:    LIST FILE ATTRIBUTES
 START WITH WHAT FILE: PATIENT//
      GO TO WHAT FILE: PATIENT//
      Select SUB-FILE:
Select LISTING FORMAT: STANDARD//
Start with field: FIRST// .03  DATE OF BIRTH
Go to field:
DEVICE:   TELNET
STANDARD DATA DICTIONARY #2 -- PATIENT FILE        NOV 15,2012@10:43:05  PAGE 1
STORED IN ^DPT(  (1220 ENTRIES)   SITE: Central Regional Hospital   UCI: EHR,EHR
 (VERSION 5.3)

DATA          NAME                  GLOBAL        DATA
ELEMENT       TITLE                 LOCATION      TYPE
-------------------------------------------------------------------------------

2,.03         DATE OF BIRTH          0;3 DATE (Required) (audited)

              DOB
              INPUT TRANSFORM:  S %DT="EP" D ^%DT S X=Y K:1701231>X!(DT<X) X I
                                $D(X) D BIRTH^DGLOCK
              OUTPUT TRANSFORM: NUMDATE4(DOB)
              LAST EDITED:      SEP 04, 2009
              HELP-PROMPT:      Enter the patient's DATE OF BIRTH which must be
                                later than 12/31/1870.  DATE OF BIRTH cannot be
                                a date after the beneficiary 'Ineligible Date'
                                or a date after the 'Enrollment Application
                                Date'.
              DESCRIPTION:      Enter the patient's DATE OF BIRTH which must be
                                later than 12/31/1870.  DATE OF BIRTH cannot be
                                a date after the beneficiary 'Ineligible Date'
                                or a date after the 'Enrollment Application
                                Date'.

              AUDIT:            YES, ALWAYS
              GROUP:            DEMOG
              NOTES:            XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER

              CROSS-REFERENCE:  2^ADOB
                                1)= S ^DPT("ADOB",$E(X,1,30),DA)=""

                                2)= K ^DPT("ADOB",$E(X,1,30),DA)

              CROSS-REFERENCE:  ^^TRIGGER^2^.083
                                1)= K DIV S DIV=X,D0=DA,DIV(0)=D0 S Y(1)=$S($D(
                                ^DPT(D0,0)):^(0),1:"") S X=$P(Y(1),U,20),X=X S
                                DIU=X K Y S X=DIV S X="1" S DIH=$G(^DPT(DIV(0),
                                0)),DIV=X S $P(^(0),U,20)=DIV,DIH=2,DIG=.083 D
                                ^DICR

                                2)= Q

                                CREATE VALUE)= "1"

                                DELETE VALUE)= NO EFFECT
                                FIELD)= #.083

              CROSS-REFERENCE:  2^AODS3^MUMPS
                                1)= S A1B2TAG="PAT" D ^A1B2XFR
                                2)= S A1B2TAG="PAT" D ^A1B2XFR

              CROSS-REFERENCE:  2^IVM03^MUMPS
                                1)= S IVMX=X,X="IVMPXFR" X ^%ZOSF("TEST") D:$T
                                DPT^IVMPXFR S X=IVMX K IVMX

                                2)= S IVMX=X,IVMKILL=3,X="IVMPXFR" X ^%ZOSF("TE
                                ST") D:$T DPT^IVMPXFR S X=IVMX K IVMX,IVMKILL

                                This cross-reference will check the IVM PATIENT
                                file to see if a change to this field will
                                require transmission to the IVM Center.  If it
                                does, the IVM PATIENT file entry's TRANSMISSION
                                STATUS will be set to 0 and the nightly
                                background job will transmit the updated
                                information.

                                Also, if this field is edited, this
                                cross-reference will check to see if the
                                patient requires a financial query to be sent
                                to the IVM Center (Data Collection Division
                                (DCD).


              CROSS-REFERENCE:  2^AVAFC03^MUMPS
                                1)= I ($T(AVAFC^VAFCDD01)'="") S VAFCF=".03;" D
                                 AVAFC^VAFCDD01(DA)


                                2)= I ($T(AVAFC^VAFCDD01)'="") S VAFCF=".03;" D
                                 AVAFC^VAFCDD01(DA)
                                This cross reference is used to remember that
                                changes were made to the PATIENT file (#2)
                                outside of the Registration process.  Execution
                                of this cross reference will create an entry in
                                the ADT/HL7 PIVOT file (#391.71) and mark it as
                                requiring transmission of an HL7 ADT-A08
                                message.

                                The local variable VAFCFLG will be set to 1 if
                                the cross reference is not executed because the
                                change is being made from within the
                                Registration process.

                                Execution of this cross reference can be
                                prevented by setting the local variable VAFCA08
                                equal to 1.

                                The local variable VAFCF is used to identify
                                the field edited.  This data is stored in the
                                FIELD(S) EDITED (#2.1) field in the ADT/HL7
                                PIVOT file (#391.71).


              CROSS-REFERENCE:  2^ADGRU03^MUMPS
                                1)= D:($T(ADGRU^DGRUDD01)'="") ADGRU^DGRUDD01(D
                                A)

                                2)= D:($T(ADGRU^DGRUDD01)'="") ADGRU^DGRUDD01(D
                                A)
                                This cross reference is used to remember that
                                changes were made to a monitored data field in
                                the PATIENT File (#2) required for a vendor
                                RAI/MDS COTS system.  Execution of this cross
                                reference will create an entry in the ADT/HL7
                                PIVOT file (#391.71) and mark it as requiring
                                transmission of an HL7 demographic A08 update
                                message to the COTS interface.

                                The local variable DGRUGA08 will be set to 1 if
                                the cross reference is not to be executed as
                                part of a re-indexing.


              FIELD INDEX:      ADGFMD03 (#847)    MUMPS    I    ACTION
                  Short Descr:  This x-ref calls the DG FIELD MONITOR event
                                point.
                  Description:  This cross reference activates the DG FIELD
                                MONITOR event point.  Applications that wish to
                                monitor edit activity related to this field may
                                subscribe to that event point and take action
                                as indicated by the changes that occur.  Refer
                                to the DG FIELD MONITOR protocol for a
                                description of the information available at the
                                time of the event.
                    Set Logic:  D FC^DGFCPROT(.DA,2,.03,"SET",$H,$G(DUZ),.X,.X1
                                ,.X2,$G(XQY0)) Q

                   Kill Logic:  D FC^DGFCPROT(.DA,2,.03,"KILL",$H,$G(DUZ),.X,.X
                                1,.X2,$G(XQY0)) Q
                         X(1):  DATE OF BIRTH  (2,.03)  (forwards)


The last trigger, which calls DGFCPROT is one example of this.

A part of the DGFCPROT routine has:

+39        ;Task off (Taskman) driver routine.
+40        N ZTRTN,ZTDESC,ZTIO,ZTDTH,ZTSAVE,ZTSK,DGVAR,BXREF,SUBSCR,ZTREQ
+41        S ZTRTN="INIT^DGFCPROT",ZTDESC="DG Field monitor task"
+42        S ZTIO="DG FIELD MONITOR",ZTDTH=$$NOW^XLFDT
+43        F DGVAR="DGDA","DGDA(","DGFILE","DGFIELD","DGTYPE","DGDTH","DGUSER"
            ,"DGX","DGX(","DGX1","DGX1(","DGX2","DGX2(","DGOPT" S ZTSAVE(DGVAR
            )=""
...
+50        D ^%ZTLOAD
+51        Q
    INIT   N X
+1         S X=$O(^ORD(101,"B","DG FIELD MONITOR",0))_";ORD(101," D EN1^XQOR
+2         I $D(ZTQUEUED) S ZTREQ="@"
+3         K DGDA,DGFILE,DGFIELD,DGTYPE,DGDTH,DGUSER,DGX,DGX1,DGX2,DGOPT
+4         Q


As you can see, there is the setup for calling TaskMan to invoke the DG FIELD MONITOR
entry in the PROTOCOL file #101 by calling EN1^XQOR.

I.E. this entry:
 
Select OPTION: INQUIRE TO FILE ENTRIES
OUTPUT FROM WHAT FILE:  PROTOCOL//    (3925 entries)
Select PROTOCOL NAME: DG FIELD MONITOR       DG Field Monitor
ANOTHER ONE:
STANDARD CAPTIONED OUTPUT? Yes//   (Yes)
Include COMPUTED fields:  (N/Y/R/B): NO//  - No record number (IEN), no Computed
 Fields

NAME: DG FIELD MONITOR                  ITEM TEXT: DG Field Monitor
  TYPE: extended action                 CREATOR: MARSHALL,RICK
  PACKAGE: REGISTRATION
 DESCRIPTION:   This protocol is an event point which monitors the editing of
 fields in DG* application files.  At the time of this event point, the
 following variables will be present in the environment:

         Variable        Description
         --------        -----------------------------------------------
         DGDA            DA array as exists during Fileman editing
         DGFILE          File or subfile number where changed field resides
         DGFIELD         Number of changed field
         DGTYPE          Type of cross reference action (ADD, DELETE or UPDATE)
         DGDTH           Date/time of change in $Horolog format
         DGUSER          DUZ of user that made the change
         DGOPT           Current menu option in "option_name^menu_text" format
         DGX             X array as documented for Fileman new style x-refs
         DGX1            X1 array as documented for Fileman new style x-refs
         DGX2            X2 array as documented for Fileman new style x-refs

 This protocol is triggered by "listener" cross references on selected fields.
 By employing logic such as "If DGFILE=2, DGFIELD=.361, DGTYPE="ADD", then...",
 subscribers to this protocol may take action based on edit activity which
 involves those fields.

 This event point is designed to occur only once per field editing activity.
 The DGTYPE variable can be interpreted as follows:

        o  ADD transactions indicate that data has been added to a field
           that was previously null.  The DGX, DGX1 and DGX2 arrays will
           contain the Fileman X, X1 and X2 arrays (respectively) as
           documented for the execution of 'SET' logic.

        o  DELETE transactions indicate that previously existing data has
           been deleted without being replaced.  The DGX, DGX1 and DGX2
           arrays will contain the Fileman X, X1 and X2 arrays
           (respectively) as documented for the execution of 'KILL' logic.

        o  UPDATE transactions indicate that existing data has been deleted
           and new data has been filed.  The DGX, DGX1 and DGX2 arrays will
           contain the Fileman X, X1 and X2 arrays (respectively) as
           documented for the execution of 'SET' logic.

 The naming convention used for these 'new style' cross-references for this
 Patch are as follows:

   1. All names will begin with the letter "A" to denote a non-lookup MUMPS
      cross-reference.

   2. The next characters identify the name space (i.e. Registration ="DG").

   3. The next two characters identify the field monitor utility ("FM").

   4. The next character will be "D" if the field contains a decimal. If
      there is no decimal, there will not be a "D" character.

   5. The next characters identify the field number.

 The establishment of this naming convention is intended to assist with the
 easy identification of the field monitoring utility as implemented across
 multiple field definitions.  It should be followed as additional instances of
 this utility are distributed.
ITEM: SCMC PCMM INACTIVATE ON DATE OF DEATH
ITEM: SPN REG STATUS UPDATE
ITEM: SPN REG STATUS DELETE
ITEM: FB PATIENT DATA CHANGE
ITEM: VAFC MPIPD FIELD TRIGGER
ITEM: PSU PATIENT DEMOGRAPHIC CHANGE
  TIMESTAMP: 60365,47585


On Thu, Nov 15, 2012 at 10:20 AM, Jason <jason.huang@icare.com> wrote:


    Would you mind explain in a bit detail how these HL7 events are triggered through the data dictionary? I am not getting the idea of trigger events through data dictionary.

    thanks,

    Jason


    On Wednesday, November 14, 2012 2:23:42 PM UTC-5, Chris Edkins wrote:

        I think you will find that these HL7 events are triggered through the data dictionary, which would be why you can't find the calls within the routines.  Triggers in the data dictionary are safer than putting it in option code, since any way you use Fileman to do the update, the trigger will still be fired.