Difference between revisions of "PATIENT File HL7 Triggers"
From VistApedia
DavidWhitten (talk | contribs) (Created page with "<pre> 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 "messa...") |
(No difference)
|
Revision as of 23:49, 22 January 2015
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.
