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  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 them in option code, since any way you use Fileman to do the update, the trigger will still be fired.