VistA ADT Filer Installation, Setup and Technical Guide. PO Box Charleston, SC 29416

Transcription

1 VistA ADT Filer Installation, Setup and Technical Guide PO Box Charleston, SC

2 Table of Contents Installing from KIDS... 3 Overview... 4 Acknowledgement Messages Service User... 9 ADT Filer Main Menu Option Primary Patient ID Create / Edit SISIADT HL7 INTERFACE PARAMETER Create / Edit SISIADT AUXILIARY FIELD MAP ACCOUNT NUMBER How ADT Filer Interprets events ADT Filer (Kernel) PARAMETERS Application Programmer Interface Miscellaneous Events Support ADT Filer Utilities Translating HL7 Field Values Post-Events Processing Custom Post-event Example Purge Exceptions Scheduled Option VistA HL7 Infrastructure ADT Filer Routines and Entry Points ADT Filer Graphical User Interface (Deprecated) Exceptions Context and Log Mode Common Fatal Exceptions. 118 Meaning of Exception Codes ADT Filer Version 2 Installation Checklist Summary of HL7 to VistA Data Dictionary Mappings Troubleshooting and Problem Solving Exporting and Importing Configuration Settings Testing a New Interface Uninstalling the ADT Filer [Note] Table of Contents page numbers may be offset while document is being revised. 2

3 VistA ADT Filer 1,2 Installation, Setup and Technical Guide The VistA ADT Filer 3 is a licensed software application from Sea Island Systems, Inc., distributed as a VistA KIDS 4 file. The exact file name varies with version and patch level but will generally have a form similar to the following: SISIADTJpKx.KID where J.K is the version and x the sub-version. The letter p stands for point as in decimal point. Special field-test versions of the KIDS file may have the following form: SISIADT-FACILITY-Txx.KID where FACILITY identifies the field test location and xx the test revision counter. To install the VistA ADT Filer invoke the VistA KIDS Installation options: Load a Distribution and Install Package(s). It is not necessary to disable options or protocols, or to inhibit logons. However, answer YES to the prompt, Want KIDS to Rebuild Menu Trees Upon Completion of Install? See also the ADT Filer Version 2 Installation Checklist section of this document for additional details. Install patches in sequence number order for the version of the ADT Filer installed. Patches and their corresponding release notes may be downloaded from: Be sure to read release notes prior to installing patches, in case any special preparations are needed Sea Island Systems, Inc. 2 Thanks to Richard Ohlmann of Medsphere Systems Corporation for reading a draft of earlier revisions and making many useful suggestions for improvement. 3 The VistA ADT Filer application is also referred to in this document as the ADT Interface or simply the Filer. Variants of the application name should be considered synonymous with the full name. 4 Kernel Installation and Distribution System 3

4 Overview The ADT Filer interface uses the VistA HL7 1.6 infrastructure to receive messages from a foreign system, that is, from a system that serves as the master ADT or Financial system, and is the authoritative source of information about patient demographics, present location, future appointments, and so forth. The VistA receiver of HL7 ADT information may be regarded as the authoritative source of selected clinical information about the patient, but is not the authoritative source for administrative information. ADT Filer 4

5 The flow diagrams on the preceding page illustrate the outermost layers of the ADT Filer interface. The nuts and bolts of the interface belong to the container labeled, Process in Foreground or Background at the bottom of the diagrams. This part of the interface is called Event Processing. It is the part that files patient demographics, visits and admissions, and optionally other data relevant to the patient s record in VistA. The foreground part of the ADT Filer interface receives the HL7 message from the VistA HL7 infrastructure. At this point it creates or updates the patient s account in VistA, i.e., the ADT Filer s ACCOUNT NUMBER file (# ), if appropriate. It also parses and translates the HL7 message. By translate is meant that it applies whatever rules or translation tables are specified in the SISIADT CONSTANTS file (# ) and that correspond to segments and fields or components that are present in the ADT event message. After completing these preliminary processing steps and calling Taskman to schedule event processing, the ADT Filer generates an accept acknowledgement, if required. The outline reproduced in the next page summarizes the relationship between the VistA HL7 infrastructure and the ADT Filer interface. 5

6 The ADT Filer includes many in-line rules for processing each ADT event type supported by the interface. However, in addition to these in-line or hard-coded rules, the ADT Filer also includes parameters that can be used to modify the way in which events are processed, and to customize processing on a sender-by-sender or site-by-site basis. Details of these parameters and other important implementation matters are presented in the following pages. 6

7 Acknowledgement Messages The ADT Filer does not generate or transmit deferred acknowledgement messages. However, it does call GENACK^HLMA1 to return an accept acknowledgement to the sender via the open TCP/IP channel (the received message channel), if the received MSH (field 15) and ADT Filer parameter settings so indicate. The following table summarizes how acknowledgement rules are applied in the ADT Filer context. MSH.15 VistA HL7 ADT Filer AL Always ACK Do not ACK (duplicate) NE Never ACK Never ACK ER Ignore SU Ignore Empty Never ACK ACK if and only if the parameter SISI ENABLE APPLICATION ACK is true. In addition to the parameter SISI ENABLE APPLICATION ACK, the ADT Filer can also insert a delay before generating an acknowledgement. The delay in seconds is specified as the value of the parameter SISI APPLICATION ACK DELAY. ADT Filer Acknowledgement Process 7

8 In addition to parameters listed on the preceding page, the ADT Filer Master Switch also affects acknowledgements. See the SISI MASTER SWITCH parameter description. Finally, The ADT Filer does not generate acknowledgements in debug mode (parameter SISI DO NOT TASK EVENTS valued true). 8

9 After installing the ADT Filer, unless importing a configuration from another implementation, it is necessary to perform several preliminary setup steps. SERVICE USER Use the standard VistA option Add a New User to the System to add a user such as FILER,ADT or INTERFACE,ADT or etc., that will serve for attribution of activities performed by the ADT Filer. This user should not have a primary menu or logon access and verify codes assigned. The following is an example: NAME: FILER,ADT INITIAL: HL7 SEX: MALE PREFERRED EDITOR: SCREEN EDITOR - VA FILEMAN DATE ENTERED: MAR 11,2010 CREATOR: MILLIGAN,LLOYD SSN: NAME COMPONENTS: 200 SERVICE/SECTION: IRM SIGNATURE BLOCK PRINTED NAME: ADT FILER 9

10 SISIADT OVERALL Menu Option Assign the SISIADT OVERALL menu to the user who will be responsible for configuring the ADT Filer (or use routine ^XUP to access this menu). Most configuration steps can be performed using sub-options of this menu. HL7 ADT Filer Overall Menu (SISIADT OVERALL) System Definition Menu Enter/Edit AUX Field Map [SISIADT SYSTEM DEFINITION [SISIADT AUX FIELD MAP EDIT] MENU] Enter/Edit ADT Filer HL7 Interface Parameter [SISIADT HL7 INTERFACE EDIT] Check ADT Filer Configuration [SISIADT CHECK CONFIGURATION] Create/Edit Table of Constants [SISIADT CONSTANTS EDIT] Export / Display Configuration Settings [SISIADT EXPORT CONFIGURATION] Import and File Configuration Settings [SISIADT IMPORT CONFIGURATION] ADT Filer PARAMETERS Menu Message and Interface [SISIADT PARAMETERS MENU] parameters [SISIADT MESSAGE AND INTERFACE] Event-based parameters edit [SISIADT EVENT PARAMETERS] Segments and Fields parameters [SISIADT SEGMENTS AND FIELDS] VistA-based parameters [SISIADT VISTA PARAMETERS] Miscellaneous Parameters edit [SISIADT MISC PARAMETERS] Display Options [SISIADT Display HL7 ADT Filer DISPLAY OPTIONS] Configuration [SISIADT DISPLAY CONFIGURATION] Print ADT Filer Exceptions [SISIADT PRINT EXCEPTIONS] Show HL7 message [SISIADT MESSAGE DISPLAY] 10

11 Display last ADT Filer patch installed [SISIADT DISPLAY LAST PATCH] Chronological Transactions for Patient [SISIADT TRANSACTION CHRONOLOGY] Utility options [SISIADT Reprocess ADT Filer HL7 UTILITIES MENU] Message [SISIADT REPROCESS HL7 MESSAGE] Point ACCOUNT NUMBER to movement/visit [SISIADT POINT ACCOUNT NUMBER] 11

12 Primary Patient ID Auxiliary field map One of the most important functions performed by the interface is to identify the patient. When a new patient is registered the patient s primary ID (medical record number or etc.) must be stored in VistA. Similarly, when information about an existing patient is received, the ADT Filer must determine the correct identity of the patient. Failure to do so could result in registering a duplicate patient. How the ADT Filer resolves the identity of an existing patient will be explained in the COMPUTE DFN paragraph of the following section. VA VistA identifies patients by social security number (SSN). However, this identifier is not normally suitable for non-va VistA implementations. Usually the patient has one immutable identifier, but sometimes more than one. In the latter case, identifiers are usually location-specific. Three main strategies exist for storing the patient identifier or identifiers. First, the implementation may add an indexed field to the VistA PATIENT file, store the identifier there, and use that field for patient lookup in the COMPUTE DFN logic. Second, the implementation may use the PATIENT/IHS file (# ), HEALTH RECORD NO. multiple to store one or more than one location-specific patient ID. Third, the implementation may use a custom ID storage strategy, possibly a different multiple than the HEALTH RECORD NO. sub-file of the PATIENT/IHS file, or a different file entirely. The second and third strategies enumerated in the preceding paragraph involve an ADT Filer PARAMETER setting and an IMPLEMENTATION-SPECIFIC API, respectively. They will be explained in more detail later in this Guide. The first strategy, to use an indexed field in the PATIENT file (or another file that relates unambiguously to the PATIENT file) will be described here, because if this strategy is employed it is necessary to define a Primary Patient ID auxiliary field map and then to specify its name in the SISIADT HL7 INTERFACE PARAMETER file, which will be discussed in the next section. To create a new auxiliary field map, use the following option: HL7 ADT Filer Overall Menu (SISIADT OVERALL) System Definition Menu Enter/Edit AUX Field Map [SISIADT SYSTEM DEFINITION [SISIADT AUX FIELD MAP EDIT] MENU] 12

13 Respond to prompts as appropriate for the file and field# that will be used to store the primary patient ID. The following is only an example. Note that each implementation may use different HL7 data sources or different target file/field# combinations. User responses are colored red. Select System Definition Menu Option: Enter/Edit AUX Field Map EVENT DRIVER PROTOCOL: SISIA ADT-A04 SERVER Foreign System Interface ADT- A04 Server HL7 SEGMENT: PID Patient Identification HL7 SEQUENCE: 3 HL7 COMPONENT: 1 HL7 SUBCOMPONENT: HL7 DATA TYPE: ST String FILEMAN FILE: 2 FILEMAN FIELD: Note: This is an example only! IENS: SISIDFN_"," IENR(1): CUSTOM TRANSFORM: SCREEN: ORDER: -1 EXTERNAL: SAVEIENS: FIND: BRIEF DESCRIPTION: Primary patient ID [Example] Select FRIEND PROTOCOL: SISIA ADT-A05 SERVER Foreign System Interface ADT-A05 Server Are you adding 'SISIA ADT-A05 SERVER' as a new FRIEND PROTOCOL (the 1ST for this SISIADT AUXILIARY FIELD MAP)? No//Y (Yes) ORDER: -1 IENS: SISIDFN_"," Select FRIEND PROTOCOL: SISIA ADT-A01 SERVER Foreign System Interface ADT-A01 Server Are you adding 'SISIA ADT-A01 SERVER' as a new FRIEND PROTOCOL (the 2ND for this SISIADT AUXILIARY FIELD MAP)? No// Y (Yes) ORDER: -1 IENS: SISIDFN_"," Select FRIEND PROTOCOL: 13

14 Primary Patient ID Other Considerations If the primary patient ID will be filed to the Health Record No. multiple of the PATIENT/IHS file, or to an implementation-specific multiple that similarly depends on location, the ADT Filer must be able to identify the facility to which the identifier belongs, both at the time of filing and when looking up an identifier. The link to VistA facility is accomplished by referring to the sending facility field of the message header, and using this value to identify the corresponding VistA INSTITUTION (File 4) entry. The convention is to make the sending facility value an identifier of the INSTITUTION entry, for the ADT FILER coding system. Refer to multiple field #9999 in File 4 for each entry that corresponds to a facility (receiver of ADT transactions). Create an entry in this multiple named ADT FILER and insert as the ID value the same exact string (case-sensitive) as is found in the MSH sending facility field (for that facility). The ADT Filer uses a special cross-reference to identify the VistA INSTITUTION from this value. The HEALTH RECORD FAC. field in File is DINUM ed to File , which in turn is DINUM ed to File 4. 5 Other location-based identifier schemes may refer directly or indirectly to File 4. Several patient ID convenience functions may be found in routine ^SISIADFN. One must take care, however, to avoid calling a patient ID function recursively (i.e. inadvertently through a chain of ID calls). Finally, the implementation may use (or not) the social security number. Default social security number validation code is included at VSSN^SISIAUTL. This code first looks for an implementation-specific SSN API in File The user-defined API is invoked if it exists. Otherwise, the default code rejects various known test SSN formats. If SSN is important in the implementation, it is recommended to use an implementationspecific API to override and strengthen the ADT Filer s built-in validation. 5 The term DINUM means that the internal entry or sub-entry number is set to the internal value of the field. 14

15 SISIADT HL7 INTERFACE PARAMETER File The ADT Filer uses a parameter file to enable or disable various modes of operation and, to define key installation-specific constants. Use the following option to create and edit entry 1 in this file. HL7 ADT Filer Overall Menu (SISIADT OVERALL) System Definition Menu Enter/Edit ADT Filer HL7 Interface Parameter [SISIADT HL7 INTERFACE EDIT] The following paragraphs explain the meaning of expected responses for each field in the SISIADT HL7 INTERFACE PARAMETER file. The edit option will branch around fields that are not relevant, based on responses entered for previous fields. LOG STATUS: The ADT Filer logs unexpected occurrences to the SISIADT EXCEPTION file. The Filer may also record informational messages, useful in debugging the interface. Logging should not normally be DISABLED. However, use VERBOSE and VERY VERBOSE settings only during the initial configuration and testing phases to investigate difficulties, as these settings cause many informational log entries to be created. NORMAL is the recommended LOG STATUS setting for a production implementation. The ADT Filer makes many calls to Fileman database server API's. For most of these calls, Fileman errors are unlikely, due to pre-screening of input parameters. However, in certain contexts, the database server may report an error back to the ADT Filer. When LOG STATUS is set to INCLUDE DIERR, the ADT Filer's exception record will record selected DIERR reports in the exception type <EVN>: DIERR 'context', where <EVN> stands for an event type A01, A02, etc., and DIERR is a constant. A routine name or other contextual information (up to 9 characters) may be included in the exception code name. Fileman database server errors do not necessarily indicate a malfunction in the interface. For example, a field map may be designed to file data in one context and not in another context. To interpret the meaning and significance of any exception, including these log status level 4 exceptions, it is necessary to examine what actually happened in relation to expectations within the exception context. The ADT Filer includes an option SISIADT PURGE EXCEPTIONS TASK that can be scheduled to run nightly or weekly to purge old exceptions. It is recommended to schedule this task whenever the LOG STATUS is set to a value higher than NORMAL in a production environment, i.e., in an environment that receives a significant volume of ADT event messages, and also records a large volume of informational exceptions. 15

16 PIMS HL7 USER: VistA patient registration and movement options require attribution to a user. This field should point to the service user entry in the NEW PERSON file that was described on page 1 of this Guide. This user will appear as the ENTERED BY or LAST EDITED BY user, and so forth, for ADT Filer mediated transactions. PRIMARY PATIENT IDENTIFIER: This field identifies the auxiliary field map that defines the VistA primary patient ID, both in the HL7 message and in VistA. This map may or may not be applied in message post-processing (controlled by the IENS). Regardless, it plays a key role in new patient registration. Normally, PID.2 or PID.3 will contain the source data from the ADT master system for unique patient identification. In VistA, the target for primary patient ID may be a standard VistA field or a new field (possibly a new file) that is not part of the VA VistA data dictionary. A PRIMARY PATIENT IDENTIFER field map is not required for filing the HEALTH RECORD NO. from file , or when using an implementation-specific API to register the patient. PRIMARY ELIGIBILITY CODE: If valued this parameter will override the default primary eligibility, which is HUMANITARIAN EMERGENCY. PERIOD OF SERVICE: If a value is entered for this parameter it will override the ADT Filer's default HUMANITARIAN value. Note that if this field is not a required identifier, and if the parameter SISI IGNORE FOIA REQ FIELDS is valued YES (true), PERIOD OF SERVICE will not be filed as part of new patient registration. COMPUTE DFN: VistA normally identifies patients through Social Security Number (SSN). Non-VistA systems typically use a different value, such as a Medical Record Number to identify patients. This field informs the ADT Filer how to compute the patient s internal entry number (DFN) from data in the received message. Any segmentsequence in the message body may be referred to indirectly, Variable SISID1 is the HL7 component delimiter. M code in this field MUST begin S DFN= Here is an example entry S DFN="" N PID3P1 S PID3P1=$G(@SISIPMSG@("PID",3.1)) Q:'$L(PID3P1) S DFN=$$FIND1^DIC(2,,"X",PID3P1,"SIS") The above example says to use the value supplied in PID.3.1 to lookup the patient s internal entry number using a cross-reference named SIS in the PATIENT file (File 2). A04: ENABLE: Selected individual ADT-Ann 6 events processing may be enabled or disabled. For example, to enable register a patient, A04 should be set to ENABLE. The default is enabled, if this field is not valued. In general, all ADT-Ann events should be set to ENABLE for an inpatient interface. 6 HL7 message types for admissions, discharges and transfers. 16

17 The response to some event enable fields affects branching, i.e. the subset of interface parameter prompts that will be presented following the current one. A08: ENABLE: To enable update patient information A08 should be set to ENABLE. See also A04: ENABLE for general considerations. A01: ENABLE: To enable admit/visit notification A01 should be set to ENABLE. See also A04: ENABLE for general considerations. Disabling A01 causes the edit process to skip fields that relate only to admission processing. REGISTER ONLY: Some senders do not support A04 and instead register patients as part of the A01 transaction. If it is desired to register patients only, but not to admit them, and if the registration event will be an ADT-A01, then set REGISTER ONLY to YES. Note that by default the Filer will register new patients from either A04 or A01 events. Note that if REGISTER ONLY is set to yes, other correlated inpatient events, including change outpatient-to-inpatient, inpatient transfer, and inpatient discharge are also disabled. SPECIALTY TRANSFER (ADMISSION): A specialty transfer movement, identifying the ward location, room-bed and provider, etc. normally accompanies manually created VistA admission movements. Answer YES to create the specialty transfer on admission, or NO to prevent creation of this bound movement. The recommended response is YES. Specialty transfer movements should be disabled only under exceptional circumstances or for testing. AUTO-CREATE PTF: If this field is answered NO the ADT Filer will not automatically create a PTF 7 entry for admissions. The normal answer is YES. Note that patients cannot be discharged without a PTF entry. If a patient is admitted without a corresponding PTF entry it is necessary to use the option Establish PTF Record from Past Admission before discharging the patient. CHAIN EVENTS: Patient movement transactions in VistA trigger follow-on events, such as to notify Nursing on admission, or discontinue medications on discharge. These events also include serving HL7 messages to additional subscribers that may include other external systems or archival databases, etc. If CHAIN EVENTS is answered NO then none of these notifications or messages, etc. will be triggered. If answered YES then post processing events will be triggered, and subscriptions must be controlled through adding or deleting ITEMs from appropriate extended action protocols, such as SISIA MOVEMENT EVENTS (actions to be performed after creating or deleting patient movements). DEFAULT SOURCE OF ADMISSION: VistA admissions require a SOURCE OF ADMISSION value, which is a pointer to file #45.1. Enter in this field the default value to be used by the Filer. This may be a standard entry, such as 2A or an entry created in file #45.1 expressly for the Filer s use. 7 VistA Patient Treatment File. 17

18 ADMISSION MOVEMENT TYPE: This parameter may be left unvalued, but should be valued for implementations that do not use standard FOIA File movement types. The value of this parameter replaces the ADT Filer s default DIRECT admission movement type in VistA-based implementations. For implementations that use FOIA File entries, the parameter may be valued or left unvalued, depending on whether or not the default VistA DIRECT is acceptable for the implementation. Note that the Indian Health Service implementation RPMS populates File entries differently than FOIA VistA. Thus for inpatient RPMS implementations it is necessary to specify a value for this parameter field. WARD TRANSFORM: This field contains an expression to compute the VistA ward, usually from the point-of-care component of the patient location specified in the inbound message. The expression returns the ward location internal entry number from message data. When the expression is evaluated the variable X has all components of the PV1.3 assigned patient location field (e.g. WARD^ROOM^BED^etc.), with spaces (ASCII 32) removed. Depending on context, the location value may come from PV1.3 or from another HL7 segment-sequence. Regardless, the value will be found in X when this expression is evaluated. The expression s form must correspond to the expression part of a set variable=expression command, where the variable will be set to the VistA WARD LOCATION (File 42) internal entry number. Do not enter a MUMPS command or the argument of a SET command. Instead enter only the right side of the = in a SET. To illustrate, not SET Y=$$F(X), not Y=$$F(X), instead only $$F(X). If the absence of spaces from the patient location components in variable X interferes with the lookup algorithm, then substitute an appropriate message value, in place of variable X in the compute expression, e.g., $$EVAL^SISIAV26( {PV1.3} ) ROOM-BED TRANSFORM: This field is analogous to the preceding field, except that it computes the VistA ROOM-BED internal entry number. Again, all components of the HL7 location (with spaces removed) are given in the variable X. The expression form corresponds to the right side of = in an M set command. COMPUTE PRIMARY PHYSICIAN: This MUMPS code should set variable X equal to the primary physician internal entry number in File 200. This value will override the value that would otherwise be computed using the INBOUND PROVIDER VISTA FILE and INBOUND PROVIDER VISTA XREF fields. The MUMPS code may call an extrinsic function to perform a lookup, based on one or more fields or components of the HL7 message. The parsed message is available Thus, for example, $G(@SISIPMSG@("PV1",17.1)) should have the "Admitting doctor" ID number (code) from the sending system. It is only necessary to supply MUMPS code to compute the primary provider, if the default method based on the INBOUND PROVIDER... fields does not suffice. Note 18

19 that the value computed will be used to populate the PRIMARY PHYSICIAN field of the specialty transfer movement associated with an inpatient admission. COMPUTE ATTENDING PHYSICIAN: This MUMPS code should set the variable X equal to the attending physician internal entry number in File 200. This value will override the value that would otherwise be computed using the INBOUND PROVIDER VISTA FILE and INBOUND PROVIDER VISTA XREF fields. The MUMPS code may call an extrinsic function to perform a lookup, based on one or more fields or components of the HL7 message. The parsed message is available Thus, for example, $G(@SISIPMSG@("PV1",7.1)) should have the "Attending doctor" ID number (code) from the sending system. It is only necessary to supply MUMPS code to compute the attending physician, if the default method based on the INBOUND PROVIDER... fields does not suffice. Note that the value computed will be used to populate the ATTENDING PHYSICIAN field of the specialty transfer movement associated with an inpatient admission. INBOUND PROVIDER VISTA FILE: Taken together, this field and the next two may substitute for the previously described COMPUTE PRIMARY PHYSICIAN and COMPUTE ATTENDING PHYSICIAN fields. Instead of code to compute PROVIDER internal entry numbers, these fields specify the target VistA data element where the external provider s identity may be resolved. INBOUND PROVIDER VISTA FILE points to the file of files (file #1). Choose a VistA file such as NEW PERSON that includes the provider s (external) ID number (as furnished in the HL7 message). INBOUND PROVIDER VISTA FIELD#: Identify the field within the file named in the preceding paragraph that stores the external system ID number. For example, if the file is NEW PERSON, the field could be 53.3 (VA#). It is necessary to enter the canonic field number, not the field name for this element. INBOUND PROVIDER VISTA XREF: If the field identified in the previous paragraph has an index, then identify the cross-reference here. To follow the previous example, the VistA NEW PERSON file VA# field has a PS2 cross-reference. TO ASIH: Enter MUMPS code to set $TEST=1 if and only if a potential duplicate admission should be processed as a transfer TO ASIH. The variable DFN exists at the time this code is executed. ASIH refers to a VA movement sequence called Absent Sick in Hospital. This sequence is used when a Long Term Care (LTC) facility holds a bed, while the patient is treated in a related Acute Care facility. (Both facilities must be configured in the same VistA database.) VistA accommodates transfers from LTC to acute care holding the LTC bed for 30 days. At the time of the transfer a +30 day discharge movement is created (i.e., a future discharge from LTC). 19

20 During the acute care episode the patient can be transferred within acute care or discharged back to LTC (called From ASIH provided the acute episode is <30 days), or discharged from LTC (called While ASIH ). Whether a discharge is processed as From or While by the ADT Filer is determined by the account number. If the account is the acute care account, then it is From. If the account is the LTC account, then it is While. Non-VA systems (senders of ADT messages) are usually unaware of how ASIH works, and in particular do not know the 30 day rule, although they may implement the same or a similar rule. It is important, however, that if ADT Filer ASIH processing is enabled, that the personnel who generate these transactions understand how they will be interpreted in VistA. Note that it is possible for a patient to be discharged From ASIH after the LTC discharge date has passed. This event will not automatically cancel the LTC discharge or create a new LTC admission. The first and most obvious ASIH decision point is To ASIH. When is an otherwise duplicate admission (albeit for a different account) really a transfer to ASIH? The apparent duplicate may be an expected occurrence in other contexts, such as an admission that was first processed as a pre-admit or processed as an inpatient admit in VistA (outpatient in the sender), etc. in which cases data should be updated for the existing admission in VistA. The key point is that the candidate admission cannot be processed as an original admission movement in VistA because the patient is already an inpatient (in VistA). Generally the To ASIH rule would do something like this: 1) If the patient is currently admitted to Long Term Care, and 2) If the current admission message specifies a different account than the LTC admission, and 3) If the new patient location is acute care, then process To ASIH. The foregoing is only an example. The rule can be more complex, specifying other message elements, etc., and of course it is assumed that separate LTC and acute facilities (VistA INSTITUTION file entries) exist in the VistA database. TO ASIH MOVEMENT TYPE: This parameter may be left unset, but should be defined for implementations that do not use standard FOIA File entries. The default value is TO ASIH (IEN=10). FROM ASIH MOVEMENT TYPE: This parameter may be left unset, but should be defined for implementations that do not use standard FOIA File entries. The default value is FROM ASIH (IEN=33). A02: ENABLE: To enable transfer a patient A02 should be set to ENABLED. See also A04: ENABLE for general considerations. 20

21 Note that ADT-A02 should be enabled in almost all inpatient interface configurations. TRANSFER MOVEMENT TYPE: This parameter may be left unset, but should be defined for implementations that do not use standard FOIA File entries. If valued, this field replaces the default INTERWARD TRANSFER (IEN=11) for the transfer TYPE OF MOVEMENT. TO LOA MOVEMENT TYPE: This parameter may be left unset, but should be defined for implementations that do not use standard FOIA File entries. The default value is TO AUTHORIZED ABSENCE (IEN=16). FROM LOA MOVEMENT TYPE: This parameter may be left unset, but should be defined for implementations that do not use standard FOIA File entries. The default value is FROM AUTHORIZED ABSENCE (IEN=14). A03: ENABLE: To enable discharge/check-out visit A03 should be set to ENABLED. See also A04: ENABLE for general considerations. Disabling A03 causes the edit process to skip fields that relate only to discharge processing. DEFAULT DISCHARGE TYPE: VistA discharge movements require a type (pointer to file #405.1). Again, the default entry may be standard, such as NON-VETERAN, or a pseudo-entry created in #405.1 for use by the Filer. COMPUTE VISIT LOCATION: This MUMPS code should set the variable X equal to the HOSPITAL LOCATION internal entry number corresponding to the visit location. If this field is not valued, the ADT Filer defaults to a "C" cross- reference lookup on the HOSPITAL LOCATION file, based on the value in PV1.3.1, or its mapped equivalent. The MUMPS code in this field overrides the ADT Filer's default computed visit location. The code may call an extrinsic function that performs a more complex lookup, based on one or more fields in the HL7 message. The parsed (and possibly translated) message is available INPATIENT PRE-ADMIT LOCATION: This MUMPS code should set the variable X equal to the WARD LOCATION internal entry number corresponding to the inpatient pre-admit location. If this field is not valued, the ADT Filer defaults to a "C" crossreference lookup on File 42 (SYNONYM field), based on the value in PV1.3.1, or its mapped equivalent. MUMPS code in this field overrides the ADT Filer's default computed inpatient pre-admit location. The code may call an extrinsic function that performs a lookup, based on one or more fields in the HL7 message. Parsed (and possibly translated) message fields may be referenced using the $$EVAL^SISIAV26(...) API. 21

22 Prior to introduction of this field, the ADT-A05 event processing code computed the location of an inpatient pre-admit from the (possibly transformed) value in PV By default, inpatient pre-admits result in a VistA SCHEDULED ADMISSION entry (or update to an existing entry). The WARD field (#8) receives the value of the location to which the patient will be admitted. Some senders do not populate component PV1.3.1 for ADT-A05 messages. The present field allows the patient's admit location to be computed from relevant data found elsewhere in the message. COMPUTE APPOINTMENT LOCATION: This MUMPS code should set the variable X equal to the HOSPITAL LOCATION internal entry number corresponding to the appointment location. Variable SISILRID has AIL.3 value. If this field is not valued, the ADT Filer defaults to a "C" cross- reference lookup on File 44, based on the value in AIL.3, or its mapped equivalent. COMPUTE APPOINTMENT PROVIDER: This MUMPS code should set the variable X equal to the appointment provider in the format required by the 'MAKE APPOINTMENT' API, typically File 200 IEN. The code may call an extrinsic function that performs a lookup, based on one or more fields in the HL7 message. The parsed message is available For example, the external provider ID may be obtained from $G(@SISIPMSG@("AIP",3)) or from another appointment message segment and field, as documented by the sender. PATIENT (2) DFN: This code computes the DFN (internal entry number) of patient (2) when the ADT event involves two patients, i.e. when the message contains two PID segments. CHANGE PPID DFN: The MUMPS code stored in this field computes the DFN (internal entry number) of an existing patient for the ADT-A47 'Change Patient Identifier List' event, as well as possibly in other events, involving only ONE patient. (This field was added in patch SISIADT*2.0*13. ) When the ADT event involves more than one patient, the other patient is identified by the MUMPS code in the PATIENT (2) DFN field. Both fields, when valued, should set the variable DFN. When the event includes changing a primary patient identifier, the CHANGE PPID DFN field should resolve to the DFN of the existing patient. In other words it should evaluate to the OLD patient identifier. It is assumed that the COMPUTE DFN field will resolve the patient ID based on the new identifier AFTER the identifier has been changed. To clarify further, in the ADT-A47 context, the present field CHANGE PPID ID will generally use data from the MRG segment (MRG.1) to identify an existing patient. The 22

23 COMPUTE DFN logic would fail, before the ADT-A47 is processed. In fact COMPUTE DFN must fail, as otherwise the new target PPID would belong to another patient. SAVE MSG HFS PATH: The ADT Filer can save inbound HL7 messages to a host file after processing is complete. This may be useful during initial configuration and debugging, but should not be valued in production implementations. An entry in this field signals the Filer that the message should be saved and also specifies the path where it should be written. It is important to ensure that the Filer has permission to create and write a text file to the specified path. Here is an example path: /home/user/messages/ SAVE MSG SCREEN: If a path is specified without a screen then all received messages will be saved to the named path. However, a screen may be used to filter messages, for example, to save only a particular event type. The term SCREEN as used in this and other ADT Filer contexts is analogous to the term s usage in Fileman. Just as the variable DIC( S ) screens lookups in Fileman, so also ADT Filer screens allow or filter various sub-processes, depending on the context of their usage. The SAVE MSG SCREEN should consist of M code to set the $TEST system variable. The screened message will be saved if and only if $Test is has message field values and the variable SISIEVN has the message event type. Thus, for example the following example screen says to save only messages that concern Inpatient Admissions: I $G(SISIEVN)="A01"&($G(@SISIPMSG@("PV1",2))="I") Select DIVISION: (Reserved). This sub-file supports division-level parameters similar to those described above for system-wide application. DIVISION level parameters are not currently implemented. 23

24 SISIADT AUXILIARY FIELD MAP Definition In addition to emulating VistA registration and patient movement manual options, the ADT Filer supports filing data to VistA fields from message elements that were not processed as part of the main emulation. This updating takes place at the end of event processing. It is best to think of updating as occurring at one point in time, after the patient has been registered or admitted or discharged, etc. However, it is also possible to specify a sequence of updates that must be performed in a specified order. This auxiliary updating of VistA fields depends upon entries in the SISIADT AUXILIARY FIELD MAP file ( ). Entries may be created using the SISIADT AUX FIELD MAP EDIT option. Entries may also be created or edited using Fileman, but not without difficulty. Presently, the #.01 field of the SISIADT AUXILIARY FIELD MAP file is a compound key that includes the internal entry number of an event-driver protocol. Therefore, entries are meaningful only in the system where they were created. (Protocols have different internal entry numbers in different systems.) However, templates (SISIA EXPORT AUX FIELD MAP and SISIA EXPORT TEMPLATE) can be used to export map entries to a host file in a standard <tab>-delimited format. A corresponding program utility IMPORT^SISIAUT1 may be used to restore and re-point map entries that were saved from another system. Similarly, the ADT Filer s configuration export and import entries properly resolve protocol internal entry numbers when processing field maps. Application-wide variables are available to use when creating a map entry. For example, the variable SISIDFN refers to the patient internal entry number and variable SISIPMDA to the patient movement internal entry number (in the appropriate context). See the Application Programmer Interface section of this Guide for a list of variables that may be referenced in auxiliary field map entries or in implementation-specific APIs. To enter/edit an auxiliary field map, use the menu option highlighted below: HL7 ADT Filer Overall Menu (SISIADT OVERALL) System Definition Menu Enter/Edit AUX Field Map [SISIADT SYSTEM DEFINITION [SISIADT AUX FIELD MAP EDIT] MENU] The following is a moderately complex example that files ethnicity information as a DINUM ed entry in the PATIENT file ETHNICITY INFORMATION multiple for A01, A04, A05, and A08 events. 24

25 Enter/Edit AUX Field Map Example: EVENT DRIVER PROTOCOL: SISIA ADT-A08 SERVER Foreign System Interface ADT-A08 Server HL7 SEGMENT: PID Patient Identification HL7 SEQUENCE: 22 HL7 COMPONENT: 1 HL7 SUBCOMPONENT: HL7 DATA TYPE: ST String FILEMAN FILE: 2.06 FILEMAN FIELD:.01 IENS: "?+1,"_SISIDFN_"," IENR(1): +HDATA CUSTOM TRANSFORM: +X SCREEN: ORDER: 5 EXTERNAL: SAVEIENS: FIND: BRIEF DESCRIPTION: ETHNICITY INFORMATION WITH DEFAULT SOURCE Select FRIEND PROTOCOL: SISIA ADT-A01 SERVER Foreign System Interface ADT-A01 Server Are you adding 'SISIA ADT-A01 SERVER' as a new FRIEND PROTOCOL (the 1ST for this SISIADT AUXILIARY FIELD MAP)? No// Y (Yes) ORDER: 5 IENS: "?+1,"_SISIDFN_"," Select FRIEND PROTOCOL: SISIA ADT-A04 SERVER Foreign System Interface ADT-A04 Server Are you adding 'SISIA ADT-A04 SERVER' as a new FRIEND PROTOCOL (the 2ND for this SISIADT AUXILIARY FIELD MAP)? No// Y (Yes) ORDER: 5 IENS: "?+1,"_SISIDFN_"," Select FRIEND PROTOCOL: SISIA ADT-A05 SERVER Foreign System Interface ADT-A05 Server Are you adding 'SISIA ADT-A05 SERVER' as a new FRIEND PROTOCOL (the 3RD for this SISIADT AUXILIARY FIELD MAP)? No// Y (Yes) ORDER: 5 IENS: "?+1,"_SISIDFN_"," Select FRIEND PROTOCOL: After entering the above, it is prudent to check and verify the entry using INQUIRE TO FILE ENTRIES. This option will display the above example as: COMPOUND KEY: 4331~PID~22.1 EVENT DRIVER PROTOCOL: SISIA ADT-A08 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 22 HL7 COMPONENT: 1 HL7 DATA TYPE: ST FILEMAN FILE: 2.06 FILEMAN FIELD:.01:.01 ORDER: 5 IENS: "?+1,"_SISIDFN_"," CUSTOM TRANSFORM: +X BRIEF DESCRIPTION: ETHNICITY INFORMATION WITH DEFAULT SOURCE FRIEND PROTOCOL: SISIA ADT-A01 SERVER ORDER: 5 IENS: "?+1,"_SISIDFN_"," FRIEND PROTOCOL: SISIA ADT-A04 SERVER ORDER: 5 IENS: "?+1,"_SISIDFN_"," 25

26 FRIEND PROTOCOL: SISIA ADT-A05 SERVER ORDER: 5 IENS: "?+1,"_SISIDFN_"," IENR(1): +HDATA It is possible to specify a SCREEN that enables or disables filing a particular field map value, thereby making the filing conditional, based on contextual values. Finally, a computed IENS from one field map entry may be saved for use in another, provided the sequence order is controlled. The auxiliary field map entry that saves the IENS must have a lower ORDER value then the entry that reuses the IENS. The following are a few additional illustrative examples. Note that the COMPOUND KEY field value is constructed by the option, not by the user explicitly. COMPOUND KEY: 3670~PID~11.1 EVENT DRIVER PROTOCOL: SISIA ADT-A28 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 11 HL7 COMPONENT: 1 HL7 DATA TYPE: ST FILEMAN FILE: 2 FILEMAN FIELD:.111:.111 IENS: SISIENS CUSTOM TRANSFORM: $$UC^SISIUTL(X) BRIEF DESCRIPTION: PATIENT'S STREET ADDRESS [LINE 1] COMPOUND KEY: 3670~PID~11.2 EVENT DRIVER PROTOCOL: SISIA ADT-A28 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 11 HL7 COMPONENT: 2 HL7 DATA TYPE: ST FILEMAN FILE: 2 FILEMAN FIELD:.112:.112 IENS: SISIENS CUSTOM TRANSFORM: $$UC^SISIUTL(X) COMPOUND KEY: 3670~PID~11.3 EVENT DRIVER PROTOCOL: SISIA ADT-A28 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 11 HL7 COMPONENT: 3 HL7 DATA TYPE: ST FILEMAN FILE: 2 FILEMAN FIELD:.114:CITY IENS: SISIENS CUSTOM TRANSFORM: $$UC^SISIUTL(X) COMPOUND KEY: 3670~PID~11.4 EVENT DRIVER PROTOCOL: SISIA ADT-A28 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 11 HL7 COMPONENT: 4 HL7 DATA TYPE: ST FILEMAN FILE: 2 FILEMAN FIELD:.115 IENS: SISIENS CUSTOM TRANSFORM: $$FIND1^DIC(5,,"X",$$UC^SISIUTL(X),"C") BRIEF DESCRIPTION: PATIENT ADDRESS: STATE COMPOUND KEY: 3670~PID~11.5 EVENT DRIVER PROTOCOL: SISIA ADT-A28 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 11 HL7 COMPONENT: 5 HL7 DATA TYPE: ST FILEMAN FILE: 2 FILEMAN FIELD:.116:.116 IENS: SISIENS CUSTOM TRANSFORM: $$UC^SISIUTL(X) At the time of evaluating the CUSTOM TRANSFORM field, the variable X contains the HL7 message value referenced by segment, sequence and component, etc. The example entries above cause the Filer to populate the patient street address fields from PID.11 data. Each address field corresponds to a different component of PID sequence 11. Friend Protocols: It would be tedious to create separate map entries for different event protocols when the objective is to file data from a particular segment and field to the same VistA target location. This situation arises when two or more protocols, 26

27 possibly dealing with similar events can each supply the same data. To accommodate this situation the map file includes a FRIEND PROTOCOL sub-file. The example on page 13 illustrates the use of the FRIEND PROTOCOL construct. Here is another: COMPOUND KEY: 3670~PID~13.1 EVENT DRIVER PROTOCOL: SISIA ADT-A28 SERVER HL7 SEGMENT: PID HL7 SEQUENCE: 13 HL7 COMPONENT: 1 HL7 DATA TYPE: ST FILEMAN FILE: 2 FILEMAN FIELD:.131:.131 IENS: SISIENS FRIEND PROTOCOL: SISIA ADT-A31 SERVER ORDER: -5 IENS: SISIENS In the above example both SISIA ADT-A28 SERVER and SISIA ADT-A31 SERVER messages are able to update PID.13.1 (patient s home phone number) Note that the order 5 (negative 5) in this example applies to the ADT-A31 friend protocol not to the ADT-A28 primary protocol. ORDER determines the sequence order in which the Filer processes map entries. Negative orders are processed before null order entries, which precede positive orders. Order usually does not matter, (and does not matter in this particular example) but could be important if it is desired to compute, then save and reuse an IENS, or in any case where updating a field depends on a previous update to another field. Note also that beginning with patch SISIADT*2.0*4, when processing auxiliary field map entries, the ADT Filer permits a message component value to be empty, but requires that the transformed value be non-empty. For example, a computed value may be specified in the CUSTOM TRANSFORM field to replace an empty component value for filing. However, if after transforming, the value is empty (whether or not the message field was valued), the field map will not process. HL7 Visit Number: An ADT Filer field HL7 VISIT NUMBER has been added to the VISIT file as field# , subscript 29320, "^"-piece 1. This field can be used to record the sender's VISIT NUMBER, usually PV The ADT Filer does not explicitly file data to this field. However, the field may be referenced in an auxiliary field map entry. For example, EVENT DRIVER PROTOCOL: SISIA ADT-A01 SERVER A01 Server HL7 SEGMENT: PV1 Patient Visit HL7 SEQUENCE: 19 HL7 COMPONENT: 1 HL7 SUBCOMPONENT: HL7 DATA TYPE: ST String FILEMAN FILE: FILEMAN FIELD: IENS: SISIVSIT_"," IENR(1): CUSTOM TRANSFORM: $TR(X,U,"~") SCREEN: ORDER: 8 EXTERNAL: SAVEIENS: Foreign System Interface ADT- 27

28 FIND: BRIEF DESCRIPTION: External VISIT NUMBER Select FRIEND PROTOCOL: (Etc.) FRIEND PROTOCOL multiples for ADT-A04, -A05, -A06, and -A07 would be typical. The HL7 VISIT NUMBER field also has a REGULAR INDEX named "SIS" that can be used for both lookup and sorting. 28

29 ACCOUNT NUMBER When the ADT Filer was first released, VistA did not have an Account Number file. In fact, the concept of patient account was essentially unused in VistA. Later, File 375 (PFSS ACCOUNT) was introduced as part of the VA s PFSS project. However, the structure of File 375 did not lend itself as a suitable replacement for the ADT Filer s ACCOUNT NUMBER file ( ). The ACCOUNT NUMBER file serves to link the sending system s patient account number to inpatient movements and outpatient visits in VistA, and hence is of central importance to the interface. As presently designed, the ADT Filer requires that each assigned patient account number (usually PID.18.1) will apply to the same patient for the lifetime of the application; in other words, the ADT Filer expects that patient account numbers will not be reused by the sender. The foregoing assumption is not supported by all sending systems. In practice, some senders may reuse account numbers, so that over the long term the same account number could apply to more than one patient. Thus, the assumption that patient account numbers are unique is not always safe in the long term. 8 The ADT Filer includes two parameters that affect how patient account number is stored in VistA. The parameter SISI FORMAT ACCOUNT NUMBER causes the sending facility (VistA institution) prefix to be included in the account number, as it is stored in VistA. This parameter was introduced to accommodate multiple sending facilities that share one VistA database, and have possibly overlapping account number domains. The parameter SISI USE PID.3 AS ACCOUNT substitutes a patient identifier for the account number. This parameter was introduced to accommodate interfaces that do not transmit account-based ADT events, but rather only patient information events, for example A28 and A31. For a detailed description of these parameters see the following section of this document (ADT Filer (Kernel) PARAMETERS). In addition to parameters that affect the stored account number format, the ADT Filer's SISIADT CONSTANTS file provides a VistA-level mechanism to translate the received account number in almost any way desired. Thus it is possible, using a File entry, to make the stored account number unique, even if the received account number is not unique, by crossing its value with another unique value, such as the primary patient ID. It is not possible to change the ACCOUNT NUMBER format in an existing production environment without careful preparation, to protect or convert previously stored values. Do not apply account number translation to a running production account, without thorough study and prior conversion of selected existing entries. 8 Thanks to Richard Ohlmann of Medsphere for calling attention to this problem. 29

30 The following example File entry illustrates how account number could be transformed to a unique value by crossing with a patient identifier. TABLE NAME: ACCOUNT NUMBER HL7 SEG.SEQ[.COM[.SUB]]: PID.18.1 TRANSLATION RULE: X_"-"_$$EVAL^SISIAV26("{PID.3.1}") DESCRIPTION: Test formatting account number as a cross of account x MRN. Screen checks a global node to enable / disable test. SCREEN: I $G(^XTMP("SIS","FORMAT ACCOUNT NUMBER")) In the example, the SCREEN is a switch that applies translation for testing purposes only. Such a simple screen would not be suitable in a production environment. A production screen would likely need to distinguish between an active account and an old (potentially reused) account. The means of doing this would be implementationspecific, depending, for example, on factors, such as the type of facility (acute vs. long term care, etc). Processing a pair of test messages with the above example translation enabled produced the following File entry - ACCOUNT ID: FC TRANSACTION CONTROL ID: PATIENT: CXXXX,FXXXXXXXX, EVENT TYPE: A01 TRANSACTION CONTROL ID: PATIENT: CXXXX,FXXXXXXXX, EVENT TYPE: A11 PATIENT: CXXXX,FXXXXXXXX, DATE/TIME: OCT 07, 2011@08:20:28 CLASS: INPATIENT DATE/TIME: OCT 07, 2011@08:22:15 CLASS: INPATIENT The first two hyphen-pieces of the ACCOUNT ID are the PID.18.1 value, while the third hyphen-piece is the first patient ID number in PID.3. The preceding example illustrates how the ADT Filer, as designed, can be made to store a unique transform of the patient account number in VistA. This approach could be used when configuring a new ADT Filer implementation, but should not be applied to an existing production implementation without substantial preparation and testing. When anticipating that an existing implementation will reuse old account numbers, design and test a screen that will distinguish new uses of old account numbers from valid references to the actual old accounts. It can be challenging to identify the relevant account when troubleshooting an abnormal occurrence. To facilitate identification of the account involved, an indexed DATE CREATED field has been added to the ACCOUNT NUMBER file. This field is also an IDENTIFIER of the ACCOUNT NUMBER file. Thus, when looking up a patient s accounts, the list of choices will include the DATE CREATED for each account, for example: 1 CXXXX,FXXXXXXXX ZZ CXXXX,FXXXXXXXX Nov 1, CXXXX,FXXXXXXXX ZZ CXXXX,FXXXXXXXX Dec 2, CXXXX,FXXXXXXXX ZZ CXXXX,FXXXXXXXX Apr 30, CXXXX,FXXXXXXXX ZZ CXXXX,FXXXXXXXX May 14, CXXXX,FXXXXXXXX ZZ CXXXX,FXXXXXXXX Jun 5,

31 Another useful troubleshooting tool is the display option Chronological Transactions for Patient [SISIADT TRANSACTION CHRONOLOGY]. The option prompts for the PATIENT to display, then an optional date range. Pressing 'Enter' for START DATE defaults to the earliest date, and for END DATE defaults to the last transaction date. The Chronological Transactions for Patient option lists all transactions in the ADT Filer's ACCOUNT NUMBER file, for the given patient and range, in the order of date/time processed. Normally, processing order is the same as the order in which messages were received. If a patient had more than one active account during the date range of interest, then transactions will be displayed in the order they were processed, across active accounts. In other words, the account number may change between successive transactions in the listing. (Account number is centered on a separate line in the display.) The option to display transactions in chronological order can be useful in troubleshooting patient location issues. The ADT Filer may have changed an inpatient s location due to data received in a message about another account, for example. * * * If it is necessary to change an existing account number, the previous account number can be stored as an ALIAS ACCOUNT entry. This multiple field, introduced in patch SISIADT*2.0*15, is cross-referenced (index G ). However, the ADT Filer does not currently include implementing code for updating patient account number. In the absence of such implementing code, the ADT Filer will create a new ACCOUNT NUMBER record for each unique patient account number received. 31

32 How ADT Filer Interprets Events The following table outlines the ADT Filer s interpretation of HL7 ADT message events. In many cases, details of how events will be processed in VistA depend upon the setting of ADT Filer Kernel parameters, as will be described in the next section of this document. ADT Event Patient Class Default ADT Filer Action A01 I O Optionally register a new patient. Create inpatient admission movement and correlated specialty transfer. Process post-movement events. Optionally register a new patient. If parameter settings allow, create an outpatient visit. A02 I O Patient must exist in VistA and have a current admission. Process a VistA transfer movement and post-movement events. Not meaningful to ADT Filer. A03 I O Patient must exist in VistA and have a current admission. Process a VistA discharge movement and post-movement events. Patient must exist in VistA and have a visit for the current account. Check-out the VistA visit and process outpatient events. A04 I O Register a new patient in VistA. Conditionally process an inpatient admission, based on a parameter setting. Register a new patient in VistA. Conditionally process an outpatient visit, based on a parameter setting. A05 I Process a VistA scheduled admission. Conditionally process an actual inpatient admission, based on a parameter setting. O Not meaningful to ADT Filer. However, may be processed by an implementation-specific event handler. A06 I Simulate an inpatient A01 plus an outpatient A03. O Not meaningful to ADT Filer. 32

33 A07 I O Not meaningful to ADT Filer, except in implementationspecific context. Simulate an inpatient A03 plus an outpatient A01/4. A08 I O Update inpatient (PV1-based) fields and patient demographics. Update patient demographics. A09 Not supported by the ADT Filer A10 Previously processed as an appointment plus visit. A10 event processing has been deprecated and is not currently supported by the ADT Filer. A11 I Cancel inpatient admission O If patient has a current inpatient admission for the account, cancel the admission. If the relevant parameter is set, and if the patient has a current appointment, cancel the appointment. Otherwise cancel an outpatient visit for the account, if such exists. A12 I Cancel most recent inpatient transfer for the account. O Not meaningful to ADT Filer A13 I Cancel inpatient discharge for the account. O Cancel outpatient visit check-out (delete check-out date/time). A17 Execute SWAP PATIENTS implementation-specific API. Post-event processing is disabled for this event. A21 I Process VistA inpatient transfer to leave-of-absence O Not meaningful to ADT Filer A22 I Process VistA inpatient transfer from leave-of-absence O Not meaningful to ADT Filer A28 Supported only in the a specific interface context. 33

34 A31 If parameter SISI PROCESS ADT-A31 AS A08 is set, update patient demographics. Otherwise, this event is supported only in a specific interface context. A34 A36 A38 A47 Process MERGE PATIENT INFORMATION A34 implementation-specific API. Not supported by the ADT Filer (Inpatient) Respects SISI ADMIT INPATIENT PREADMITS parameter. (Outpatient) Cancels visit. Change the primary patient identifier (one ID) 34

35 ADT Filer (Kernel) PARAMETERS In addition to its parameter file (SISIADT HL7 INTERFACE PARAMETER) the ADT Filer uses many so-called Kernel parameters. These parameters are defined in the VistA PARAMETER DEFINITION file and valued in the PARAMETERS file. To enter/edit data for these parameters by the group or context to which they belong, use the following menu options: HL7 ADT Filer Overall Menu (SISIADT OVERALL) ADT Filer PARAMETERS menu Message and Interface [SISIADT PARAMETERS MENU] parameters [SISIADT MESSAGE AND INTERFACE] Event-based parameters edit [SISIADT EVENT PARAMETERS] Segments and Fields parameters [SISIADT SEGMENTS AND FIELDS] VistA-based parameters [SISIADT VISTA PARAMETERS] Miscellaneous Parameters edit [SISIADT MISC PARAMETER] It is also possible to enter/edit parameter values individually, using the VistA option Edit Parameter Values [XPAR EDIT PARAMETER] or routine ^XPAREDIT. The following alphabetical listing describes how Kernel parameter settings affect or control ADT Filer behavior. Use one of the options described above to examine or modify Kernel parameter values. SISI A04 PROCESS UPDATE EVENTS Process update post-events for A04 If set to YES the post-events processor will unwind the SISIA UPDATE EVENTS protocol for A04 as well as A08 events. The default is A08 only. SISI ADMIT INPATIENT PREADMITS Process inpatient A05's as admissions ADT-A05 messages with patient class (PV1.2) = "I" by default produce SCHEDULED ADMISSION entries. This parameter can override this default behavior by creating an actual admission movement (generally a future admission), either for NEW patients only or for ALL inpatient preadmits. The value 0=NEVER is the same as leaving this parameter unvalued, i.e., process as a VistA SCHEDULED ADMISSION. When processing a scheduled admission, if a scheduled admission already exists for the current account or if a scheduled admission exists for the same combination of patient by reservation date/time, the existing scheduled admission will be updated based on information in the current 35

36 message and the current TRANSACTION CONTROL ID entry in the ACCOUNT NUMBER file will be pointed to the possibly revised SCHEDULED ADMISSION entry. Note that if an existing scheduled admission was previously canceled, fields pertaining to the cancellation, i.e. fields #13, #14, #15, and #16 will be cleared (values deleted). SISI ADT FILER URL ADT Filer patch distribution URL This URL may be used by a notification option to check for new ADT Filer patches. The format of patch file names is generally SISIADT_<VER>_SEQ-nn_PAT-mm[Txx].KID, where <VER> denotes the version, nn the sequence order number, mm, the patch number, and xx the revision number (if any). The option that accesses the URL in this parameter will download the page contents and parse the available patch file names. If a patch is found that has not been completely installed, as indicated by the STATUS of the INSTALL file entry for the patch, then an exception, "Please install patch" will be recorded, and optionally an alert will be issued, if so configured. SISI ADT-A28 UPDATE PATIENT patient Allow ADT-A28 to update existing When set to YES this parameter causes the ADT Filer to update patient information when an ADT-A28 is received for an existing patient. [Applies to A28 / A31 interface only, e.g. Medical Manager] SISI APPLICATION ACK DELAY Application ACK delay in seconds For use in pacing incoming message processing, when the link has been shutdown and restarted. With 0-seconds delay (default), many messages can be processed concurrently. A small value in this field may be useful in controlling the rate of incoming messages. [Fractional seconds are permitted.] See also the SISI SINGLE-THREAD EVENT TASKS parameter. An application ACK delay is not needed or recommended when single-threading of event processing is enabled. SISI ASSOCIATE VISIT Associate VISIT entries to ADT Filer By default, VISIT entries created by the ADT Filer HL7 interface are associated with the PCE package. (The ADT Filer did not have a PACKAGE file entry in version 1.8.) This parameter allows visits created by the interface to be associated with the ADT FILER package. If this parameter is valued 1=YES (True) it will also be necessary to edit the VISIT TRACKING PARAMETERS file entry, in order to add the ADT FILER as an ACTIVE PACKAGE in this file (150.9). In order to attribute VISIT creation to any package, that package must be listed as ACTIVE in the VISIT TRACKING PARAMETERS file entry. Before creating a VISIT, the ADT Filer will check both the value of this parameter AND the VISIT TRACKING PARAMETERS file 36

37 entry. Unless both values coincide the created VISIT will be associated with the default PCE package, as before. SISI DAYS TO KEEP EXCEPTIONS Days to retain ADT Filer exceptions This parameter works in conjunction with the SISIADT PURGE EXCEPTIONS TASK option to protect exceptions from purging for the specified number of days. This parameter has no effect if the SISIADT PURGE EXCEPTIONS TASK option is not scheduled. If the purge exceptions option IS tasked, but this parameter is not valued, 'days to keep' defaults to 7 days. SISI DEFAULT FAC DIR EXCLUSION Default FACILITY DIRECTORY EXCLUSION This parameter is applicable in the inpatient admission context only, including ASIH admissions. If valued, the parameter will cause the specified default value to be filed in field# 41 of the admission movement entry. If this parameter is not valued, field# 41 will be left blank. Prior to introduction of this parameter, the ADT Filer did not file a value in field# 41 in its in-line admission processing code. To file a message-based value in this field, it is necessary to define an auxiliary field map entry for this purpose. If a field map is defined, it will override the default value, i.e., this parameter's value. If no value is specified for this parameter, and if no message-based value if filed via an auxiliary field map, a 'Patient Inquiry' type display will include the following - Patient chose not to be included in the Facility Directory for this admission. The logic underlying the above quoted display is found in routine DGPMV10, which in effect interprets a missing value in field# 41 the same as an affirmative (EXCLUDE) value, as long as the patient is currently admitted to the facility. To summarize, leaving this parameter unvalued will cause the ADT Filer (and the 'Patient Inquiry' display) to behave in the same way as before the parameter was implemented. If this parameter is valued, then the specified value will be filed for field# 41 FACILITY DIRECTORY EXCLUSION at the time an inpatient admission or ASIH movement is processed. Whether the parameter is valued or not, a true message-based value may be filed using a suitably constructed SISIADT AUXILIARY FIELD MAP (File ) entry. Use the ADT Filer option 'Enter/Edit AUX Field Map' to create an auxiliary field map. 37

38 SISI DEFAULT VISIT LOCATION Default VISIT Location Used when creating a VISIT or OUTPATIENT ENCOUNTER for which no location was specified. If the environment includes multiple HL7 sending facilities, this location is the default OVERALL location (not sending facility-specific). SISI DELETE COMPLETED TASKS Delete completed event TASKS If this parameter is valued YES (true) event processing tasks (entries in the ^%ZTSK global) will be deleted after events are processed, provided that no MUMPS error occurs during processing. Deleting completed tasks is the usual and recommended action. However, if this parameter is valued NO (or not valued), tasks will not be deleted after completion SISI DELETE INSURANCE ENTRIES updating Delete insurance entries before This parameter causes the ADT Filer to delete all entries from the patient's TYPE multiple before processing insurance segments for the current message. The effect is that each update replaces previous insurance information for the patient. This parameter has no effect when the message being processed contains no IN1 segments. SISI DISALLOW A08 MRN UPDATE Disallow ADT-A08 to update MRN In the following description, the term MRN refers to the patient primary identifier, as configured in the ADT Filer interface. If this parameter is not valued, or valued NO, an ADT-A08 can update the patient MRN based on a match to ACCOUNT NUMBER. The purpose of allowing such an update is to accommodate patients who were registered in VistA using a pseudo-mrn, but with a valid ACCOUNT NUMBER, during foreign system downtime). When the foreign system (sender) is back up, it can assign a true MRN (after the patient is registered to that system). The above-described behavior is incompatible with some senders, and not supported in HL7, which defines an event ADT-A47 specifically for changing patient identifiers. To prevent an ADT-A08 from changing the patient primary identifier (MRN) based on patient account number, set this parameter to YES. If this parameter is valued YES (true) the VistA patient identified by the account number will be updated, even if the MRN is unknown. In other words, when the present parameter is valued YES (true), the MRN (primary patient ID) will be ignored, once the patient has been identified by account number in the ADT-A08 context. 38

39 SISI DISALLOW FILING SSN Do not create or delete SSN This parameter overrides filing or editing or deleting the patient social security number in VistA (File 2, field #.09). If not valued, SSN will be filed or updated, or a pseudo-ssn will be filed, according to the other processing rules in effect for this field. If valued YES, this parameter overrides all other rules, including the VALIDATE SSN implementation-specific API and prevents the ADT Filer from creating, modifying or deleting the SSN field of the VistA PATIENT file. It remains possible to file SSN through an auxiliary field map entry or post-event protocol. However, it is recommended to check the value of the application-wide variable SISINOSS in these contexts, and NOT file SSN if this variable value is '1' (TRUE). SISI DISALLOW FUTURE OPT VISIT Disallow opt visit > x mins in future If this parameter is not valued, the ADT Filer will create outpatient visits for the specified date/time (usually PV1.44), whether the date is in the past, present or future. If this parameter is set to '0', outpatient visits in the future (defined as a time greater than the time the event was processed) will not be created. If this parameter is set to a positive number, future outpatient visits will be allowed up to the number of minutes specified by the value entered. The purpose of this value is to allow visits to be created for the present day (or in the next day if close to midnight, etc.) and also to forgive small differences in clock time between the sending system and VistA. For example, if a value of 10 is entered, visits will be allowed up to 10 minutes in the future, with reference to the time the event is processed in VistA. If a value of 1440 is entered, visits will be allowed up to 24 hours (1440 minutes) from the time the event is processed. This parameter affects only outpatient visits, and not inpatient admission visits, which are created for the same date/time as the admission movement. SISI DO NOT CREATE OPT VISIT Do not create outpatient VISIT entries The parameter SISI DISALLOW FUTURE OPT VISIT controls the creation of outpatient VISIT entries for a FUTURE date/time. The current parameter prevents creating outpatient VISIT entries for ANY date/time. If this parameter is valued YES, the ADT Filer will not create outpatient VISIT entries for events that would otherwise result in a new outpatient VISIT. Thus, this parameter overrides other rules that result in outpatient VISIT creation. 39

40 This parameter does not affect the creation of INPATIENT ADMISSION VISIT entries. Thus an inpatient admission movement will have a corresponding admission VISIT, regardless of this parameter's value. A value of NO is the same as not valued, and allows outpatient VISIT entries to be created under the conditions allowed by other parameter settings. SISI DO NOT TASK EVENTS Do not task event processing The ADT Filer normally performs only minimal core processing in the HL processing thread, and then schedules event processing to complete in a separate (background) process. Setting this parameter to YES (true) causes event processing to be completed in the original HL thread, rather than as a separate process. Setting the value to NO (false) is the same as not setting a value. Event processing will be scheduled through VistA Taskman. Note: The SISI DO NOT TASK EVENTS parameter may be deprecated in the future. This parameter should not be valued YES (true), except when debugging. In other words, the ADT Filer should not be configured to process events in the HL7 thread in any production implementation. Instead, the parameter SISI SINGLE-THREAD EVENT TASKS should be used to control sequencing of event tasks. See the description of the latter for more details. SISI DO NOT USE EVN.6 Ignore 'Event Occurred' time stamp Patch SISIADT*2.0*9 replaced the use of 'Date Time Planned Event' and 'Recorded Date/Time' fields in the event type segment, with the 'Event Occurred' time, if the latter is valued. The purpose of this parameter is to override this change and cause relevant times to be computed as they were before the patch. This parameter's value affects ADT-A02 'transfer' events, as well as ADT-A06 'change outpatient to inpatient', and other similar events whose interpretation requires information about date/time not available from other segments/fields. If this parameter is not valued or is valued in the negative, the change introduced in patch SISIADT*2.0*9 will be effective. If this parameter is valued in the affirmative, all relevant event times will be computed in the same way as they were before the patch. SISI ENABLE APPLICATION ACK ADT Filer Enable Application ACK Causes ADT Filer to generate an Application (commit) ACK to the sending system prior to processing the received message. SISI ENABLE K-ADT EVENTS Enable Keane PATCOM Adaptors This parameter controls whether selected ADT events are processed in the usual way or are routed through routine ^SISIADTK, which performs Keane PATCOM pre-processing. This parameter should be left unvalued in most implementations. A value of NO for this parameter overrides the Sending Application Name PATCOM, causing messages from PATCOM to be processed by the ADT Filer s generic event handler, with no special 40

41 pre-processing. A value of YES causes messages from non-patcom senders (SAN) to be pre-processed as if they were PATCOM messages. SISI EXCLUDE PATIENT TYPES Exclude patient type(s) This field enables identification of patient types that do not correspond to real human patients, for example, commercial accounts or contract accounts used for reference lab billing and so forth. If this parameter is valued, and any ";"-piece of the value is equal to the PV1.18 patient type code field value, then message event processing will be skipped. SISI FILE PRIMARY ID TO HRN No. File primary pat ID to Health Record This parameter is used by the ADT Filer's new patient registration code (ADT-A04 processing) to determine whether or not to create an entry in sub-file (HEALTH RECORD NO.) for the primary patient identifier, usually PID.3. Some multi-facility implementations use the Health Record No. multiple in File for facility-specific patient ID s. The facility is mapped to the HIS LOCATION file, which is DINUM ed to File 4. Other multi-facility implementations may choose to use a custom multiple identifier. The ADT Filer does not assert how patients should be identified, either at the facility or enterprise level. However, whatever method is implemented must uniquely identify the patient and distinguish unambiguously between an existing patient (previously registered in VistA) or a new patient. SISI FILTER CHARACTERS Filter non-standard (control) character This parameter can be used to filter spurious characters, specifically control characters, from the parsed message. The X-Link to VOE sender terminates segments with ASCII 13,10 in place of the standard ASCII 13 only. It is therefore necessary to remove the ASCII 10 (line feed) character, which precedes the 3-character segment ID. Setting this parameter value to 10 will remove the character from the parsed message. Note that this parameter setting does not affect how the message is stored in the MESSAGE file (controlled by VistA HL7 infrastructure). SISI FORMAT ACCOUNT NUMBER Include Facility Prefix in Account This flag informs the ADT Filer whether or not to cross the sending facility prefix with the account number in PID.18 to make up the.01 value for the ACCOUNT NUMBER entry in VistA. In addition to ACCOUNT NUMBER, the patient's HEALTH RECORD NO. (Field.02 in multiple ) format will be similarly affected by the setting of this parameter. 41

42 The default is NO. If NO the ACCOUNT NUMBER entry consists of PID.18 exactly. If YES the entry consists of a 3-letter prefix that identifies the sending facility followed by the PID.18 value. Similarly the patient's HEALTH RECORD NO. will be either the unmodified PID.3.1 value or a 3-letter prefix followed by the PID.3.1. value. Note that the three letter prefix value comes from File 4, field #100 OFFICIAL VA NAME. This has nothing to do with VA, as referenced in this context. The field has no particular meaning in non-va contexts and can be used to store a facility prefix, correlated to the INSTITUTION entry. The correct INSTITUTION is resolved through the IDENTIFIER multiple #9999, which should contain an entry for CODING SYSTEM: ADT Filer. The ADT Filer looks up the MSH.4 value in this IDENTIFIER multiple using an application-specific index. Once the INSTITUTION entry has been identified, the ADT Filer computes the prefix from field #100, as previously indicated (if this parameter is valued YES). SISI FORMAT TRANSACTION ID Add EVENT TYPE to TRANSACTION CONTROL ID The TRANSACTION CONTROL ID multiple in the ACCOUNT NUMBER file uses the HL7 message control ID as the #.01 field value by default. Some senders use the same message control ID for paired messages, which causes data for the first message to be overwritten by data for the second message in the ACCOUNT NUMBER file's TRANSACTION CONTROL ID multiple (transaction history). Setting this parameter to YES causes the event type to be appended to the message control ID as the value of the #.01 field, thus making the entry unique. For example, if the message control ID was 1234 and the event type was A08, then the #.01 will be 1234-A08. Setting the parameter to NO has the same effect as leaving it unvalued. The entry for the example would be #.01 = SISI GUARANTOR AS INSURANCE Process Guarantor as Insurance Setting this parameter to Y[ES] (true) causes the ADT Filer to create and process a pseudo-in1 segment for guarantor data. This segment uses the name GUARANTOR for the insurance company. GUARANTOR should preexist in the INSURANCE COMPANY file (unless the SISI INSURANCE COMPANY LAYGO parameter is also valued Y[ES]). Note that this parameter only uses the guarantor segment (GT1) as the source or data to be processed into the INSURANCE TYPE multiple of the PATIENT file, i.e. not to the RPMS GUARANTOR file or to any guarantorrelated fields in VistA. Guarantor data are mapped as follows: 42

43 Processed as pseudo IN1 sequence IN1.4 IN1.6 IN1.7 IN1.63 IN1.12 IN1.13 IN1.16 IN1.18 IN1.19 IN1.43 SISI IGNORE FOIA REQ FIELDS Source of data Constant "GUARANTOR" GT1.45 contact person GT1.6 guarantor phone GT1.6 guarantor phone GT1.13 effective (begin) GT1.13 expiration (end) GT1.3 name of insured GT1.8 date of birth GT1.5 address GT1.9 sex Ignore FOIA required fields Causes ADT Filer to skip veteran-specific fields that are required identifiers in the FOIA version, e.g. VETERAN Y/N? Fields that are required identifiers can be determined using Fileman. Required (or not) and identifier (or not) are separate independent attributes of each field. If a field is both required and an identifier then it must be valued in a call to the database server API that creates the record. Otherwise the new entry is not created. SISI IGNORE RACE REPETITIONS Do not process RACE field repetitions If valued 'Y' YES only the original RACE identifier PID.10.1 will be filed and repetitions of this field will be ignored. If not valued, the default is to process all RACE identifiers in PID.10, including repeats. SISI INP ADM LOC PRE-CHECK Inpatient admission location pre-check If this parameter is set to 'YES' the ADT Filer will evaluate the inpatient WARD LOCATION, prior to creating an admission movement. If the WARD LOCATION is missing or invalid, the movement will not be created. If this parameter is 'NO' or not valued, the ADT Filer will create the admission movement before evaluating WARD LOCATION. This is the way the interface worked prior to introducing this parameter. When creating an admission movement manually, the movement is first created and then WARD LOCATION is entered (via the DGPM ADMIT input template). However, in the manual context WARD is required, and the movement will be deleted if WARD is not entered. Admission movements that do not have a WARD are incomplete, and cannot be edited by ordinary methods. However, HL7 senders sometimes inform of an inpatient admission using an A01 message without a ward location, and then follow this with an A08 message providing the ward location. The ADT Filer accepts the above, provided an inpatient A01 without WARD is always followed by another message to identify the WARD. To 43

44 accommodate such a sequence, this parameter should be left unvalued (or set to 'NO'). On the other hand, if the sender always includes WARD information in the inpatient A01 message (or equivalent inpatient admission event), setting this parameter to 'YES' adds a validity check on the WARD LOCATION, preventing the creation of a defective admission movement without WARD. SISI INSURANCE COMPANY LAYGO Allow INSURANCE COMPANY LAYGO By default, an insurance company referenced in an IN1 segment must pre-exist in the INSURANCE COMPANY file (or INSURER file if IHS). This parameter allows the ADT Filer to create a new entry in File 36 for an insurance company name that fails File 36 lookup. SISI LOG RECEIVED MESSAGES Enable 'Received Messages' Log If this parameter is valued 'YES' (true), a record of messages by message control ID will be saved in File SISIADT RECEIVED MESSAGE LOG. This parameter only determines whether or not data will be filed and has no effect on how the file is used. The default is 'NO' (do not record received messages. If logging of received messages is enabled, the application-wide variable SISIMIEN will have the IEN of the current message. Otherwise this variable will contain the empty string. That is to say, variable SISIMLOG is always defined, regardless of whether or not message logging is enabled. Note also that this file does not log message content. Content is normally filed to the HL7 MESSAGE TEXT file by the VistA HL7 infrastructure, where it is retained for a period corresponding to the DAYS TO KEEP parameter value(s) in the HL7 Site Parameter file. The received message log includes utility fields DATA-1, DATA-2, and DATA-3, similar to the same named fields in the ACCOUNT NUMBER file. Auxiliary field maps or post-events may file data to these fields using the SISIMLOG current record number. When received message logging is enabled, the record also records the status of messages, i.e., whether or not completed. Although the ADT Filer does not currently use this information, it may possibly be used in a future enhancement or extension to the ADT Filer. SISI MASTER SWITCH ADT Filer master switch This parameter is similar in concept to the ACTIVE/INACTIVE switch in the SISIADT FILER HL7 APPLICATION PARAMETER entry. The setting '0' ON (or not valued) is analogous to ACTIVE. '1' OFF is analogous to INACTIVE. '2' OFF causes received HL7 messages to be discarded (not processed by the ADT Filer) but acknowledged by the ADT Filer, consistent with HL7 acknowledgment rules. 44

45 The setting '2' OFF differs from application parameter INACTIVE, in that from the sender's point of view the message will have been processed. Thus the sender will not suspend the message stream, while waiting for an acknowledgment. The setting '3' SUSPEND works in conjunction with the parameter SISI SINGLE-THREAD EVENT TASKS, causing the ADT Filer to suspend processing the current message until the SISI MASTER SWITCH has been reset to a different value. If the SISI SINGLE-THREAD EVENT TASKS parameter is not set, then the '3' SUSPEND setting will be ignored and messages will be processed normally, i.e., as if the ADT Filer master switch setting were valued '0' ON. SISI NO LOCATION UPDATE DELAY delay Suppress inpatient location update This parameter overrides the built-in (hard-coded) 2 second delay when processing an update to inpatient ward / room-bed data. Note that the delay is also overridden when single-threaded event processing is enabled. It is NOT necessary to set this parameter in addition to the SISI SINGLE-THREAD EVENT TASKS parameter. This parameter should only be set in special circumstances, when single-threading is NOT in effect, and when the timing of ADT-A08 messages is such as to render the built-in delay ineffective, or when the built-in delay causes incorrect sequencing of location updates. SISI NULL MEANS DELETE Null in selected fields causes delete When this parameter is valued YES, the ADT Filer will interpret a null (empty) field or component to mean "delete the existing value from the corresponding VistA field." This parameter does not affect ALL HL7 message fields, only two specific interpretations, both in the update processing context. The first refers to patient SSN, patient address sub-fields, and patient phone number fields. If an address changes, say from a 4 line to 3 line address, the sender generally does not indicate to delete the unused line in the previous address, i.e. using double quotes. The second interpretation refers to next-of-kin fields, name, relationship and phone numbers. This parameter was introduced to meet a specific need at one site and is probably not of general usefulness. SISI PARSED MESSAGE UNIQUE ID Parsed message unique ID number Some sending systems reuse message control IDs for different messages that have the same message and event types. By default the ADT Filer's parsed message is stored in ^XTMP(...,<Message control ID>). If this parameter is set to a non-zero value, this value will be used as the next available unique ID for storing the parsed message, and will then be incremented (recommended). SISI PARSED MESSAGE USE LVN Use local array for parsed message By default the ADT Filer stores the parsed message in the ^XTMP global, descending from ^XTMP("SISIAOUT",<SFN>,<EVN>,<ID>), where <SFN> is 45

46 the sending facility name, <EVN> is the event type, and <ID> is either the message control ID or a sequential number determined by the value of the SISI PARSED MESSAGE UNIQUE ID parameter. The current parameter causes the parsed message to be stored in a local variable (array). Note that the length of ADT messages varies widely between different event types and different senders. When this parameter is set to YES, the parsed message array (LVN) along with other important variables will be saved to the ^%ZTSK global when event processing is tasked for background processing, unless the SISI DO NOT TASK EVENTS parameter overrides (not recommended, except in a debugging context). By storing the parsed message in a local array, the risk of another process killing the parsed message is averted. However, the ADT Filer's symbol table storage requirements are substantially increased (when the parsed message array is stored as an LVN). SISI PROCESS ADT-A04 AS A01 Process 'register patient' as 'admit' If the sending applications uses ADT-A04 to create an outpatient visit (or an inpatient admission), this parameter should be set to YES. The message must necessarily include a PV1 segment, with required VISIT data, e.g. PV1.44. Sending applications exhibit considerable variability in how they use message events. VistA, on the other hand, distinguishes between outpatients and inpatients, but does not generally distinguish between various patient sub-classes. HL7 message events are therefore either pure patient demographics (registration and update), pre-admits, or outpatient or inpatient events, as interpreted by the receiver (ADT Filer -> VistA interface). The interface uses parameters, including this one, to determine the VistA-specific meaning of the sender s event. SISI PROCESS ADT-A08 AS A04 'register' Process 'update patient..' as If the sending system sends ADT-A08 to register new patients, i.e. patients who were previously unknown to VistA, this parameter may be set to YES to cause ADT-A08 (update) to process as ADT-A04 (register a patient). Note that the message event processing context becomes that of an ADT-A04. This means that if the parameter to process A04 as A01 is set, the message will be processed as an A01. If the parameter to process update events on A04 is set (recommended), then update post-events will be processed also. It should be noted that the primary use of this parameter is to facilitate pre-loading the VistA database with patient demographics at the start of implementation. Patients which have been previously registered on the sending side are unknown to VistA and therefore have to be loaded into VistA once before processing other transactions. 46

47 This is not mandatory, and some implementations register known patients in the same way as new patients, as they return for additional care. Generally, this parameter will be left unvalued. If set to YES temporarily in order to facilitate a pre-load, it is important to remember to reset the parameter when the pre-load is complete, as otherwise ADT-A08 events could be interpreted as duplicate registrations. SISI PROCESS ADT-A31 AS A08 Process 'person' as 'patient' update If the sending system sends ADT-A31 to update patient demographics or other patient information, and does not use ADT-A31 to update non-patient information (guarantors, etc), it may be desirable to process A08s and A31s in the same way, i.e. using the same event processing code. Setting this parameter to YES (true) causes ADT-A31 messages to be processed by the ADT-A08 event handler. As with other even substitution parameters it is important to be aware of dependent or domino substitutions. Thus for example, if an A08 can register a new patient, and an A31 is set to process as an A08, then an A31 will be able to register a new patient. SISI PROCESS BAR-P05 AS P01 Process 'update' as 'add' if unknown pt. If set to yes, this parameter causes a BAR-P05 message that would have caused a bad patient ID exception to register a new patient. Note that ADT Filer support for BAR messages (and other non-adt messages) is limited. BAR-P01 events process similarly to ADT-A04 (register a patient) events and BAR-P05 events process similarly to ADT-A08 (update patient information). SISI PROCESS DUP ADM AS UPDATE Process duplicate admission as update If processing would cause a duplicate admission exception, and if the message references the same account as the admission, and if this parameter is valued YES, then process the message as an update to the admission. SISI PROCESS DUP OPV AS UPDATE Process duplicate opt visit as update If this parameter is not valued or is valued NO an outpatient admission (or change an inpatient to outpatient class change, etc.) can create a second visit (or more) for the same account. When this parameter is valued YES, only one outpatient visit is allowed for an account, and a message-event that would create another visit instead updates the existing visit (date/time or location). Note that the same account can in principle have an inpatient admission visit and one outpatient visit, if this parameter is valued YES. In other words, the parameter does not prevent creating a new outpatient visit if an existing visit for the account records PATIENT STATUS IN/OUT = IN. 47

48 SISI PROCESS ETHNICITY IN-LINE Process Ethnicity Information In-Line Prior to patch SISIADT*2.0*12, Ethnicity Information was not processed by the ADT Filer's in-line event-processing code or generic update protocol. Many implementations used an auxiliary field map to file data from PID.22 to the VistA PATIENT file ETHNICITY INFORMATION multiple. This parameter enables in-line processing of ETHNICITY INFORMATION, which can be used in place of an auxiliary field map definition. However, the implementation should NOT enable in-line processing, if a field map has been previously defined and is currently being used for the same purpose. If setting this parameter value to YES, first delete or disable any auxiliary field map entry that processes data from PID.22 to the ETHNICITY INFORMATION multiple. In other words, ETHNICITY INFORMATION may be processed either by an auxiliary field map, or by the in-line code, but should not be processed by both methods in the same implementation. File is the ADT Filer's auxiliary field map file. To identify an entry that processes ethnicity information, look for the string "PID~22" or "PID~22.1" as part of the compound key (entry name). Do not delete or disable any relevant entry from the SISIADT CONSTANTS file (File ), as translation of Ethnic Group is required, regardless of the method chosen for filing. SISI PROCESS OPT A01 AS APPT Process outpatient A01 as appointment An outpatient ADT-A01 without a visit date in PV1.44 will be processed as a future appointment if this parameter is set to YES. SISI PROCESS OUTPATIENT ONLY Process only OUTpatient Class messages This parameter allows PATIENT CLASS (PV1.2) = "O" to be selected for processing, while skipping other patient classes. SISI PROCESS SIU-S17 AS S15 appointment Process 'delete' as 'cancel' If set to Y[ES] this parameter causes an appointment deletion event to be processed as an appointment cancellation event in VistA. SISI RESTRICT ADMIT DATE/TIME Apply additional validation of admit DT If valued YES, this parameter will cause the ADT Filer to perform additional movement sequence chronology checks on the admit date/time (PV1.44) before processing an inpatient admission. If these checks fail, the admission will not be processed and an exception will be recorded. If this parameter is valued NO or not valued, no additional checks will be performed on the admission date/time. 48

49 The actual checks to be performed may vary over time. Additional checks (contingent on this parameter) may be added in the future. SISI SINGLE-THREAD EVENT TASKS Single thread tasked event processing The ADT Filer receives incoming HL7 messages via a multi-threaded TCP/IP listener (under normal production conditions). Unless the 'Do not task event processing' parameter is set to YES (true), the ADT Filer schedules event processing as a background task. Under certain circumstances many events may be handled (de-queued) concurrently. This is particularly likely when the interface has been off-line for a period of time, and is restarted with a backlog of messages. The current parameter SISI SINGLE-THREAD EVENT TASKS single-threads background event processing through the use of a resource device that has only one slot. This parameter has no effect, if the SISI DO NOT TASK EVENTS parameter is valued YES (true). By single-threading event-handling, the probability of processing more than one HL7 message for the same patient or same episode of care etc. at the same time is eliminated. This should prevent out-of-sequence processing errors associated with restarting the interface after downtime, and similarly prevent lock collision problems that sometimes occur under this and other similar circumstances. However, note that if a single event process fails with a MUMPS error, or due to a system fault, or etc. the resource upon which synchronization depends will need to be cleared in order to permit event processing to resume. The DEVICE is named SIS ADT FILER RESOURCE. The supporting code for this parameter is released in ADT Filer patch SISIADT*2.0*3. The code has not been tested under heavy load conditions, prior to release. Patch SISIADT*2.0*4 extends the effect of this parameter to include using a TASK SYNC FLAG for synchronization (ordering) of event processing tasks. Thus if this parameter is valued true, the task will use both a resource device and a sync flag. If valued false, or not valued, the task will use neither a resource device nor a sync flag. SISI SIU PROCESS API Process SIU implementation-specific API When set to 'YES' this parameter causes the ADT Filer to route SIU messages to the implementation-specific (appointment) API processor, regardless of SENDING APPLICATION. The ADT Filer does not have any built-in appointment processor. SIU (appointment) messages are processed as future (planned) visits (VISIT file entries), unless the ADT Filer s internal SIU event processing code is replaced by user-supplied or implementation-specific APIs. To process SIU events as appointments, specify the processing APIs as File (SISIADT IMPLEMENTATION-SPECIFIC API) entries. Then set 49

50 this parameter (SISI SIU PROCESS API) to 'YES' to direct the ADT Filer to use these APIs. SISI SIU-S12 REGISTER PATIENT Allow SIU-S12 to register new patient When set to YES this parameter causes the ADT Filer to register a new patient when otherwise a "S12: Bad PT ID" exception would be recorded. If the SIU-S12 (or proxy) is being processed as a VISIT event, ADT registration is used by default, to load new patient data. The default, when the SIU-S12 is being processed as an implementation-specific appointment API, is BAR registration. Note that registration may be minimal, and may not include patient demographics that are present in the message PID segment, such as address, phone number, etc. These demographics may be loaded into the patient record by a subsequent ADT-A08 or BAR-P05 message. To override the default registration method, set the parameter SISI SIU-S12 REGISTRATION TYPE (SIU Patient Registration Override) to an appropriate override value. SISI SIU-S12 REGISTRATION TYPE SIU Patient Registration Override The ADT Filer can process SIU messages to VistA VISIT entries or to appointments (provided suitable implementation-specific appointment APIs are defined). By default, the ADT Filer processes SIU message events to visits. However, if the parameter SISI SIU PROCESS API is valued YES, implementation-specific appointment APIs are invoked instead. If the parameter SISI SIU-S12 REGISTER PATIENT is valued YES, SIU messages are permitted to register new patients to VistA. Otherwise the patient referenced in the SIU message must already exist in VistA. If registering a new patient is allowed, the VISIT-context SIU message processor uses the ADT message patient registration code to load new patient data into VistA. The appointment-context (implementation-specific API) SIU message processor uses the BAR message patient registration code. The present parameter overrides the default registration method. If the present parameter is valued 'ADT' (the usual case), the ADT patient registration code will be used to add a new patient in the SIU message processing context (provided this is allowed by the SISI SIU-S12 REGISTER PATIENT parameter setting. If the present parameter is valued 'BAR' (the exceptional case), BAR patient registration code will be used to add a new patient in the SIU message processing context (provided that adding a new patient is allowed by the SISI SIU-S12 REGISTER PATIENT parameter setting). 50

51 SISI SUPPRESS D.O.D. UPDATE Suppress updating date of death If this parameter is valued YES (true), date of death will not be filed or modified or deleted, unless the event is an ADT-A03 discharge. The default is to ALLOW filing and to update date of death for all event types that support updating patient demographics (ADT-A08 and any event type that has the SISIA GENERIC UPDATE enabled as a post-event. See also the SISI A04 PROCESS UPDATE EVENTS parameter and other parameters that affect update processing either directly or indirectly). Normally, information about a patient's death can come from other sources, when the patient is not currently being treated in the facility, and if conveyed via HL7 messaging this information can update the patient's date of death. When date of death is entered, inpatient pharmacy orders are automatically discontinued. Similarly outpatient prescriptions are discontinued. Other orders may also be affected. Since death could have been reported in error, and the consequences are serious, implementations may use this parameter to override filing date of death in any context other than a discharge from the facility. SISI SUPPRESS SIU PROCESSING Disable inbound SIU processing Convenience switch to disable processing received SIU messages. SISI USE EVN.2 IF EVN.3 TIME=0 Substitute EVN.2 if EVN.3 time is zero This parameter affects transfers and possibly other events, in which the planned event date/time is used as the time of the event in VistA. Some systems do not specify a time, but since the data type is TS, the message indicates a time of 00:00[:00], corresponding to the preceding midnight of the specified date. When this parameter is set to yes, EVN.3 will not be used when the time is canonically 0 (zero). Instead EVN.2 will be filed as the date/time of the event in VistA. SISI USE PID.3 AS ACCOUNT Use PID.3 as account number When set to YES this parameter causes the ADT Filer to use PID.3 in place of PID.18 as patient account number. If SISI FORMAT ACCOUNT NUMBER is also set to YES the account number will be formatted. ADT Filer patches will introduce additional PARAMETER DEFINITION entries as they are needed to support newly discovered implementation processing requirements. 51

52 Application Programmer Interface Application-wide variables: The ADT Filer defines and uses application-wide variables that are generally available for post-application processing. These include: SISIACCT Account IEN ( )^Transaction IEN ( ) SISIDFN Patient IEN (DFN) SISIPMCA Current admission movement IEN (405), in transfer, discharge, and cancel discharge event contexts. SISIPMDA Admission movement IEN (405), if applicable SISIPPID Primary patient ID from message in registration context SISIPTF Patient Treatment File IEN (45), if applicable SISISPDA Specialty Transfer movement IEN (405), if applicable SISIVSIT Visit IEN, if applicable SISIMLOG SISIADT RECEIVED MESSAGE LOG file IEN (if log enabled) SISIQUIT Abort new patient registration in COMPUTE DFN context. This variable can be set by implementation-specific duplicate checking logic, to avoid creating duplicates or multiple patient entries, when COMPUTE DFN fails. The following table compares variables SISIPMCA and SISIPMDA in inpatient postevent processing contexts: POST-EVENT VARIABLE SISIPMDA VARIABLE SISIPMCA =================================================================== A01 Admission movement IEN Empty string (null) A02 Transfer movement IEN Admission movement IEN A03 Empty string (null) Admission movement IEN A11 Admission movement IEN Empty string (null) A12 Unsupported post-event Unsupported post-event A13 Empty string (null) Admission movement IEN =================================================================== Selected message-related variables are also available in most contexts: SISID1 SISID2 SISIEVN SISIMID SISIPMSG Field component delimiter Field sub-component delimiter ADT Event Type HL7 Message Control ID Name of parsed message array Elements of the parsed message array may be referenced by segment and sequence ID, and optionally the component (if the HL7 data type includes components), for example: PID,3.1) refers to the first component of segment-sequence PID.3. See also the description of EVAL^SISIAV6(EXPRESSION)below. Routines: The following entry points are available for public use: $$GETX^SISIAPI(ACCT,CLASS) Returns the most recent admission movement or visit for the specified account. This API searches through accounts backwards from the end, or from a transaction IEN specified in $P(ACCT,U,2). The CLASS parameter is optional. If specified, only a transaction of the specified inpatient or outpatient type will be returned. If CLASS is not specified, either a movement or visit may be returned. 52

53 call is: The return format of the $$GETX^SISIAPI(ACCT,CLASS) extrinsic function ACCOUNT IEN^TRANSACTION IEN^DATE.TIME^CLASS^MOVEMENT IEN^VISIT IEN To illustrate usage, suppose the caller needs to obtain the admission movement IEN that belongs to the current inpatient episode identified in SISIACCT. The desired value would be $P($$GETX^SISIAPI(SISIACCT,"I"),U,5). $$ACCOUNT^SISIAPI(DFN,ENCDT,PMIEN,VSIEN) Returns account IEN^ID based on input parameters. Patient internal entry number DFN is required. If PMIEN (patient movement IEN) or VSIEN (visit IEN) are valued, only an account for the corresponding patient class is returned.? may be entered for one of these parameters to mean any IEN of the same class. If ENCDT (encounter date/time) is valued, then transactions that preceded the specified date/time are ignored. Only accounts having transactions (events) on or following the given date/time will be returned. When the VISIT or PATIENT MOVEMENT is known, the corresponding account for the visit or movement is returned. This information is exact, in the sense that a movement or visit can have only one account. When neither the movement nor visit IEN is argued, the API attempts to return the account that has a transaction closest in date/time to the specified encounter date/time, and that also satisfies the following requirements: 1) the account date/time does NOT precede the encounter date/time and 2) the patient type on the date/time of the selected account transaction agrees with the specified class (inpatient or outpatient). The account with the closest date/time to the date specified is usually but not always the last one created for the patient. Thus, whenever neither the visit nor movement is specified the algorithm searches all of a patient s accounts to find the best match. 9 Note that an inpatient admission visit cannot satisfy an account number search in which the? token is used for the VISIT parameter. Finally, the $$ACCOUNT API is designed to return a value if it is reasonably possible to do so. If this API fails to produce an account satisfying the exact requirements of the input parameters, it will try again to identify an account based upon relaxed parameter values. $$VERIFY^SISIAPI (<ACCOUNT NUMBER>,<PATIENT DFN>) verifies the association between an account number and patient, returning 0 for agreement or 1 for disagreement. In addition, the following error codes are returned: 9 The improved $$ACCOUNT^SISIAPI search algorithm implemented in ADT Filer patch SISIADT*2.0*10 is due to a suggestion by Joel Sher. 53

54 -1 = Invalid function call (e.g., missing or invalid parameter) -2 = Account number exists but has no associated patient -3 = Account does not exist (not found) '0' and '1' return values have no qualifying text. Negative returns are in the format "-1^explanatory text". This API may be called by an implementation-specific API or a post eventprocessing protocol, or etc. The account number parameter can specify an external account number or back quote (ASCII 96) + IEN (as in Fileman's interactive lookup). The patient DFN parameter must be an internal entry number. It is assumed that the ADT Filer's COMPUTE DFN logic has been executed, and that DFN is available to the caller. $$XACCT^SISIAPI(<account IEN>) Returns the patient account number in external format. The optional parameter may argue an ACCOUNT NUMBER IEN (File IEN). If this parameter is omitted in event or post-event processing contexts, the current message account number is returned. Note that the application-wide variable SISIACCT contains the current message account IEN^transaction IEN (two "^"-pieces). This API returns the ACCOUNT NUMBER file's ACCOUNT ID field #.01. This field value may have been formatted by the ADT Filer, i.e., if the parameter SISI FORMAT ACCOUNT NUMBER is valued YES (true). $$EVAL^SISIAV26(<PARAMETER>) This API replaces direct references to the parsed message for most purposes, providing a more general facility to evaluate expressions that contain message elements and optionally MUMPS code. This API evaluates message elements as part of an expression. Elements to be evaluated are enclosed in curly braces {}, i.e., in the format {SEG.SEQ[.COM]}. Curly braces are required to set off the message element parts of expressions. The API is an extrinsic function $$EVAL^SISIAV26(). For example, $$EVAL^SISIAV26("{PV1.3.1}") will return the value of the point of care component of the assigned patient location, if that message element is valued. Note that the caller can reference any segment, even a non- existent one, without the concern of causing an UNDEFINED condition. However, curly braces must be used to separate the HL7 element from other parts of the expression. Such elements will be evaluated, even if they are inside a literal. Message elements are evaluated using the $GET function, and therefore do not need to exist in the received message. For example, the following is a valid expression: 54

55 {PV1.3.1}="AB"&({PV2.18}=1234) The above produces the same result as: On failure, the function returns the unevaluated expression. In other words, if the expression cannot be interpreted by the $$EVAL function, the original value of the expression parameter will be returned. For example, suppose the caller omits {} and argues $$EVAL^SISIAV26("PV1.3.1"). In this case the function returns the literal that was argued "PV1.3.1" (without quotes), not the referenced message field value. Note that a valid expression in this context cannot be the argument of a SET command. Also note that care is required with quotation marks. For example, suppose that PID.5 has the value YEATS^WILLIAM^BUTLER^ (where "^" stands for the HL7 component delimiter): $$EVAL^SISIAV26("""The patient is ""_$$Q^SISIAV26({PID.5.2}_"" ""_{PID.5.1})") The above example returns The patient is "WILLIAM YEATS" $$EVAL^SISIAV26 can be called from SCREEN fields, as well as other implementation-specific contexts. For example, when defining an auxiliary field map entry for a given field, it may be desired to make filing conditional, based on the value of one or more additional fields. In this case the $$EVAL function could be called from the entry's SCREEN field to set $TEST. ACKONLY^SISIADT This entry point is not an API. However, we document it here for convenience. ACKONLY^SISIADT can be used as a SUBSCRIBER protocol's PROCESSING ROUTINE, if it is desired to disable processing an event, while acknowledging the message (to the sender). The ADT Filer generates an acknowledgement, if required, and records an informational exception (i.e., in VERBOSE or VERY VERBOSE mode). Otherwise message contents are ignored. For example, for a particular implementation it may be desired to suppress processing of ADT-A06 and ADT-A07 messages, while generating an acknowledgement to indicate that the messages were received and stored. By changing the PROCESSING ROUTINE for the SISIA ADT-A06 CLIENT and SISIA ADT-A07 CLIENT protocols from D EN^SISIADT("ADT","A06") and D EN^SISIADT("ADT","A07") respectively to D ACKONLY^SISIADT, normal event processing will be bypassed for these events only. However, the ADT Filer will acknowledge the A06 and A07 event messages if acknowledgements are otherwise required in the context. 55

56 Miscellaneous Events Support The ADT Filer includes an interface to user-supplied processing code, for events or functions which may not be handled internally by the ADT Filer. The SISIADT SUPPORTED API file (File ) documents those events for which user-defined override code are currently supported. For example, CANCEL APPOINTMENT FILE GUARANTOR DATA FILE PATIENT IDENTIFIERS MAKE APPOINTMENT MERGE PATIENT INFORMATION A34 MODIFY APPOINTMENT PRE-PROCESS EVENT RECORD EXCEPTION REGISTER PATIENT RESCHEDULE APPOINTMENT SWAP PATIENTS A17 VALIDATE INPT ADMIT D/T UPDATE VALIDATE SSN Miscellaneous Events Support Process Diagram The ADT Filer parses the HL7 message for each event and prepares documented variables for use by the user-supplied processing routine. The entry for the ADT-A17 event, for example, documents the following variables: NAME: SWAP PATIENTS A17 SUPPORTED VARIABLE: DFN1 BRIEF DESCRIPTION: Patient (1) DFN ALWAYS DEFINED: YES SUPPORTED VARIABLE: DFN2 BRIEF DESCRIPTION: Patient (2) DFN ALWAYS DEFINED: YES SUPPORTED VARIABLE: SISPLOC1 BRIEF DESCRIPTION: Assigned patient (1) location PV1.3 (raw) ALWAYS DEFINED: YES SUPPORTED VARIABLE: SISPLOC2 BRIEF DESCRIPTION: Assigned patient (2) location PV1.3 (raw) ALWAYS DEFINED: YES It is up to the user-defined routine to perform the corresponding action for the event. When appropriate code has been prepared, an entry should be made in File for the documented API, to call the user-supplied code. For example: NAME: SWAP PATIENTS A17 XECUTE: I $T(SWAP^MYRTN)]"" D SWAP^MYRTN(DFN1,DFN2,SISPLOC1,SISPLOC2) Some entries in the SISIADT SUPPORTED API file include DEFAULT XECUTE code. If present, the DEFAULT XECUTE code will be executed, unless 56

57 overridden by XECUTE code in the corresponding SISIADT IMPLEMENTATION- SPECIFIC API file. Generally speaking, DEFAULT XECUTE code, if present, is intended as an example or template to be replaced (overridden) by implementationspecific XECUTE code. In other words, the implementation should not rely upon the DEFAULT XECUTE to perform a function in a specific way that is desired. For example, the SWAP PATIENTS A17 entry in the SISIADT SUPPORTED API file has DEFAULT XECUTE: D SWAP^SISIAEX. Examining the example code in routine SISIAEX may be helpful in designing an appropriate implementation-specific API for this event. However, the example code itself may not suffice for processing the event in most situations. The name field of File is a pointer to File It is likely that additional ADT Filer supported APIs will be added to File , as interfaces are identified for other events. As well as variables documented by the ADT Filer miscellaneous events interface, the parsed HL7 message is also available to the called routine. However, it is recommended to avoid referring to undocumented message fields if possible, and instead to use the $$EVAL^SISIAV26( ) API, for example, $$EVAL^SISIAV26( {PV1.19} ). Alternatively, use the $GET function, for example $G(@SISIPMSG@( PV1,19)). As in the case for defining post-events protocols, implementation-specific code defined in the XECUTE field of the SISIADT IMPLEMENTATION-SPECIFIC API entry must not cause an M error. CANCEL APPOINTMENT FILE GUARANTOR DATA FILE PATIENT IDENTIFIERS MAKE APPOINTMENT MERGE PATIENT INFORMATION A34 MODIFY APPOINTMENT PRE-PROCESS EVENT PREP/SCREEN POST-EVENTS RECORD EXCEPTION REGISTER PATIENT RESCHEDULE APPOINTMENT SWAP PATIENTS A17 VALIDATE INPT ADMIT D/T UPDATE VALIDATE SSN Supported API s (January 2014) 57

58 ADT Filer Utilities ADT Filer utilities are under development and currently include options to display or reprocess an HL7 message and to display ADT Filer exceptions Display Options [SISIADT DISPLAY OPTIONS] Print ADT Filer Exceptions [SISIADT PRINT EXCEPTIONS] Show HL7 message [SISIADT MESSAGE DISPLAY] Utility options [SISIADT Reprocess ADT Filer HL7 UTILITIES MENU] Message [SISIADT REPROCESS HL7 MESSAGE] For example, option SISIADT PRINT EXCEPTIONS: Print ADT Filer Exceptions produces a listing of exceptions by date/time range, for example: SISIADT EXCEPTION List FEB 11,2005@07:55 PAGE 1 DATE@TIME CODE MESSAGE ID DATA FEB 11, :18:39 Cannot compute DFN FEB 11, :34 Pt never admitted FEB 11, :53:47 Cannot compute DFN For some exceptions the HL7 message ID is cited, as in the examples above. Messages can then be traced either within VistA or externally, if saved in the Interface Engine. However, when message elements have been transformed and event processing produces unexpected results, it is advisable to view the message in VistA, to be sure that the contents actually received by the ADT Filer are the values that were expected. Additional information about exceptions may be found in the SISIADT EXCEPTION TYPE file (File ). This file s contents will vary as new exceptions are added in support of code revisions introduced by ADT Filer patches. An alphabetical listing of the SISIADT EXCEPTION TYPE file s contents at the time of this writing is included near the end of this document. Tracing messages: The message control ID can usually be ascertained from the exception record, or from the ACCOUNT NUMBER file s TRANSACTION CONTROL ID multiple. In some cases it is easier to start from the PATIENT MOVEMENT FILE, which also references the ACCOUNT NUMBER file for admissions To populate the ADT FILER REFERENCE multiple in the PATIENT MOVEMENT file, add the protocol SISIA MISCELLANEOUS POST ACTIONS as an ITEM to the appropriate post-events extended action protocol, usually SISIA MOVEMENT EVENTS. 58

59 The following ADT Filer convenience option can be used to display the message (by control ID) Display Options [SISIADT DISPLAY OPTIONS] Show HL7 message [SISIADT MESSAGE DISPLAY] If the message in question has a non-unique control ID, the above option displays the HL7 message corresponding to the last instance of the given control ID. To display more than one message, sharing the same message control ID, the ADT Filer s display utility may be invoked from the programmer prompt, as follows. >DO MSG^SISIATST(<control ID>,<max number of messages to display>) To include the acknowledgement message in the display, include a third parameter value 1. >DO MSG^SISIATST(<control ID>,<max number of messages to display>,1) If it is necessary to trace a message in VistA, without using ADT Filer utilities, select Fileman option 5 INQUIRE TO FILE ENTRIES and choose file 773 HL7 MESSAGE ADMINISTRATION. At the Select HL7 MESSAGE ADMINISTRATION DATE/TIME ENTERED: prompt, enter the HL7 message ID. When message administration fields are displayed, copy the INITIAL MESSAGE date/time to the clipboard. Next inquire to file 772 HL7 MESSAGE TEXT. At the Select HL7 MESSAGE TEXT DATE/TIME ENTERED: prompt, paste the previously saved date/time. When displaying an HL7 message through Fileman it is important to be aware that the pipe character has special meaning to Fileman. Fileman translates to in the display. Thus, if the message uses as a field separator and any fields in the segment are empty, the displayed sequence count will be wrong. One workaround is to retrieve the HL7 MESSAGE TEXT internal entry number for the message, and then display the message using a global list utility or programmer command. Converting to or from base 36: One particular sending system converts an internal queue number (base 10) to a message control ID suffix (base 36). To facilitate easy identification of the message corresponding to a queue ID for this sender, the ADT Filer includes a utility function $$TO36^SISIAV2A(X) which converts a value X from base 10 to base 36. To find the queue ID for a given message control ID suffix, invoke the function $$FROM36^SISIAV2A(X) to convert from base 36 to base 10. Find the message control ID corresponding to transmission log entry >W $$TO36^SISIAV2A(320889) 6VLL 59

60 Convert message control ID XYZ-6VLL to a transmission log entry number. >W $$FROM36^SISIAV2A("6VLL")

61 Translating HL7 Field Values The SISIADT CONSTANTS file (# ) provides a convenient location to store small tables of constants, such as HL7 User Defined Tables or other custom translation tables. The ADT Filer option Create/Edit Table of Constants should be used to create and modify entries. For example HL7 Table 0063 might be defined by an entry such as the following: TABLE NAME: NOK RELATIONSHIP INPUT: 01 INPUT: 02 INPUT: 03 INPUT: 04 INPUT: HL7 SEG.SEQ[.COM[.SUB]]: NK1.3 OUTPUT: SELF OUTPUT: SPOUSE OUTPUT: NATURAL CHILD - INSURED RESP OUTPUT: NATURAL CHILD - INS NOT RESP OUTPUT: STEP CHILD In this above example, the HL7 field is a coded element (data type CE) and the VistA target field is a free text data type. 11 Many potential target fields are pointers, in which case it is necessary to specify the internal entry number of the pointed-to file as the output value for translation. It is possible to create more than one entry for the same HL7 data element, segment [component]. A SCREEN on each entry allows programming logic to determine whether or not the translations should be performed in a given processing context. The screen is evaluated prior to applying translation to HL7 field (component, etc.) values. If, on applying the screen, $TEST is false, the values in question will NOT be translated. If no screen is defined, the default is to apply the translation. Note that in general, it would not make sense to either 1) APPLY or 2) NOT APPLY a single translation. The purpose of the SCREEN is to differentially apply one of two or more translations. Thus, for example, if two independent senders are transmitting ADT messages to the same VistA database, each may use different HL7 code values for the same HOSPITAL SERVICE or the same DISCHARGE DISPOSITION or etc., or they could might the same code value for two different meanings. Normally such codes are translated, either in the Interface Engine, or in the ADT Filer s SISIADT CONSTANTS file. The SCREEN field can test the SENDING FACILITY NAME [HL variable $G(HL( SFN ))], for example, to determine which of two entries to use when translating one of these fields for different senders. In general, the ADT Filer files (stores) internal VistA values. Thus HL7 coded entries should always be translated to their VistA-equivalent values. If no table entry exists for a given HL7 data element in File , the Filer will assume that the field or component value has been pre-translated and that the value in the received message is 11 Note that the SISIADT CONSTANTS file deals with translating message body segments and fields, not with elements of the HL7 message header (MSH) segment. 61

62 valid, with the exception that some fields may have default values (specified in the ADT Filer s main parameter file 29320). Default values apply when the corresponding HL7 data element is not valued (after translation). Certain message field values require translation in nearly every sending system, in order to file correctly to VistA. Near the end of this document, the table entitled Summary of HL7 to VistA Data Dictionary Mappings describes the relationship between HL7 data elements and VistA data dictionary fields or sub-fields. The Notes column in this table indicates when a field value requires translation. An exceptional case: The discharge disposition field PV1.36 can be translated to a File internal entry number to override the default (inpatient) discharge disposition. Suppose, however, that it is desired not to override the default, but instead to process all inpatient discharges in VistA as the same type, say as REGULAR discharges. Suppose also that the message field PV1.36 is valued according to a sender-specific user-defined table (the usual case). It would be possible, of course, to translate each individual PV1.36 value (from the sender s table) to the same VistA value, say 24 for REGULAR discharge. However, there is a simpler way to override the sender s value, and instead file the default VistA value. First, set the DEFAULT DISCHARGE TYPE field of the SISIADT HL7 INTERFACE PARAMETER (File 29320) entry to the desired standard discharge type. Then create a SISIADT CONSTANTS file entry for this data element that specifies EMPTY STRING for the value of the DEFAULT TO field. Leave the INPUT OUTPUT fields unvalued. In other words, do not translate message values. This trick has the effect of replacing message values with the empty string. Here is an example entry: TABLE NAME: DISCHARGE DISPOSITION DEFAULT TO: EMPTY STRING HL7 SEG.SEQ[.COM[.SUB]]: PV1.36 In this example, the existence of a table entry for PV1.36 informs the ADT Filer that this HL7 field value should be translated. However, on looking up any value, regardless of what is in PV1.36, no translation is found. Therefore the translated value defaults to the empty string (based on the DEFAULT TO field). Finally, when the ADT Filer is processing a discharge and finds that the translated PV1.36 entry is not valued, it looks up the DEFAULT DISCHARGE TYPE field in the main parameter file and uses whatever value is specified there. 62

63 Translating HL7 Field Values Additional Features ADT Filer Version 2 patches introduced additional SISIADT CONSTANTS file fields, along with supporting code. The following paragraphs describe how these supplementary fields can be used to facilitate conversion of message values to VistAmeaningful data. Special character translation: Some characters have special meaning to Fileman and therefore cannot be entered as values for ordinary fields. For means delete, and cannot be specified as an INPUT or OUTPUT field value in a SISIADT CONSTANTS entry. However, a feature supports substituting character values (ASCII values) for characters that cannot be entered as literal field values. For example, the following INPUT OUTPUT pair translates the HL7 delete indicator "" to the Fileman delete field value INPUT: $C(34,34) OUTPUT: $C(64) 34 is the ASCII double-quote character and 64 is character. Thus, this specification says to translate two double-quotes to one at-sign (meaning delete). It is not necessary that both INPUT and OUTPUT variables have the same form. One may be an ordinary literal value, and the other a $C(...) expression. Only numeric values are accepted as arguments in the $C expression list. Thus, for example, $C(65,66,67) is okay (same as ABC), but $C($A("@")) will not be accepted. Up-arrow $C(94) also remains forbidden as INPUT. Finally, note that the form must specify $C(...), not $CHAR(...), in order to be interpreted in this way. Sequence order processing: An ORDER field has been added to the SISIADT CONSTANTS file. This field can be used to force translations (for different entries) to be applied in a specified order. This field is optional and if not valued, the entry will be processed in internal entry number order. If the ORDER field is valued, the table entry will be processed in the order specified (with respect to other table entries). All entries that have ORDER values will be processed before entries that do not have ORDER values. A low ORDER entry will be processed before a high ORDER entry. Entries with the same ORDER will be processed in their turn according to their internal entry number. Entries that do not have a specified ORDER (i.e. the ORDER field value is empty), will be processed in internal entry number order, after entries that do have ORDER values. 63

64 If no entries have ORDER values, then all entries will be processed in internal entry number order, which is the same as before the ORDER field was introduced. Thus, if the ORDER field is not used, no change in processing order will occur. Translate by rule: Another optional field TRANSLATION RULE has been added to the SISIADT CONSTANTS file. If this field is not valued the entry will be processed exactly as before this field was added. The TRANSLATION RULE field has no effect when the HL7 field or component value to be translated has a matching INPUT value in the entry. However, if the HL7 data element value does not match any INPUT value, and if a TRANSLATION RULE has been defined, the rule will be applied to the HL7 data element value. Note that the data element value must not be the empty string. The empty string cannot be translated using this mechanism. The form of the TRANSLATION RULE is an expression, i.e. the RIGHT side of a SET OUTPUT=... command. For example, if the INPUT value is "001" and this INPUT does not match a tabled INPUT value and the TRANSLATION RULE value is +X, then the computed OUTPUT will be 1. The variable X will contain the HL7 field or component value at the time the TRANSLATION RULE is applied. The precedence for translation is as follows. First match a tabled INPUT and return the corresponding OUTPUT. If there is no match for the data element value as a tabled INPUT, apply the TRANSLATION RULE (if one exists) and return the resulting OUTPUT. If the OUTPUT of both these steps is the empty string, apply the DEFAULT TO rule, to either return the empty string or the original message value. Copy From: This field identifies an HL7 SEG.SEQ[.COM[.SUB]] whose contents will be copied to the element associated with the current SISIADT CONSTANTS entry. In other words, data will be copied from the HL7 field/component defined by the COPY FROM field to the HL7 field/ component/etc. defined by the HL7 segment, field or component associated with the current SISIADT CONSTANTS entry. Functionally, a TRANSLATION RULE could be defined to copy one message field to another. However, the COPY FROM field simplifies this process, in that it is only necessary to identify the field to be copied, as SEG.SEQ.COM. Use of the COPY FROM field cannot be combined with an INPUT-OUTPUT table in the same SISIADT CONSTANTS entry. However, by judicious use of the ORDER field, two entries can be created for the same target element, the first to load values from another field using COPY FROM, and the second to translate values to suitable VistA equivalents using either an INPUT-OUTPUT table or a TRANSLATION RULE. 64

65 It is important to note that when COPY FROM is defined, the target field value will be replaced, regardless of the value of the source field. Thus if the source field is empty (or does not exist in the message) the target field will be empty, regardless of whether it had a value previously or not. DEFAULT TO becomes inoperative, when COPY FROM is in effect. Preferably, the SISIADT CONSTANTS EDIT menu option should be used when creating or editing entries in the SISIADT CONSTANTS file. Using Fileman to edit entries may result in non-meaningful combinations of field values, such as COPY FROM + DEFAULT TO. When the menu option is used, the fields presented are those that are meaningful in combination. To disable a SISIADT CONSTANTS entry that has COPY FROM defined, without deleting the entry or the COPY FROM definition, use the SCREEN field (IF 0). Another special case: The HL7 message segment NK1 includes a field (NK1.7) called Contact Role. This field specifies not the relationship, but the kind of role that is specified by the segment data. Six kinds of role are supported by the interface, based on specific groups of VistA PATIENT file fields. These roles are: 1) Primary next of kin 2) Secondary next of kin 3) Emergency contact 4) Secondary emergency contact 5) Employer 6) Death designee A special code designates which of these roles the NK1 segment data describes, hence which group of PATIENT file fields should receive data. In effect this mapping specifies user-defined Table Code Value SP NK EC E2 EM DD ADT Filer Table 0131 Description Primary next of kin Secondary next of kin Emergency contact Secondary emergency contact Employer Death designee Thus, the sender s Contact Role values must be translated to one of the codes described in the above table, in order for the NK1 data to be processed by the ADT Filer to the correct PATIENT file field group. 65

66 The reason this is an exceptional case is that the Contact Role field value is not being translated to a specific VistA field value. Rather this field s value determines how segment data will be processed in VistA. To further clarify, suppose that next of kin is designated by the sender as code CP. Then CP must be translated to SP either in the interface engine or in a File entry. While code SP suggests SPOUSE, data will be filed to Primary next of kin fields in the PATIENT file. Similarly, if EP stands for EMERGENCY PERSON, then EP should be translated to EC. In-line translation: Under certain conditions, inpatient admission events file data to the DIAGNOSIS [SHORT] field of the PATIENT MOVEMENT file. Because a classic Fileman call (^DIE) is used to edit this field, it is necessary to remove Filemansignificant characters from the value to be filed. Thus, data (strings) to be filed to the DIAGNOSIS [SHORT] field are first transformed as follows: From To HL7 encoding character HL7 escape sequence ";" semi-colon "," comma "/" forward-slant "-" hyphen "^" up-arrow "~" tilde It is recommended that, when feasible, this field be pre-processed before passing its data to the ADT Filer s inpatient admission processing code. 66

67 Post-Events Processing The ADT Filer includes extended action protocols for processing additional actions, following the completion of ADT message event processing. The most important of these is SISIA MOVEMENT EVENTS, which is analogous to the DGPM MOVEMENT EVENTS protocol that performs a sequence of actions following inpatient movement processing through VistA Bed Control options. Items may be added to the SISIA MOVEMENT EVENTS protocol. However, care should be exercised, as 1) the interface processing environment is not the same as the DGPM MOVEMENT EVENTS environment. Therefore, it is not guaranteed that everything that an action item needs will be available in the processing context. 2) Many actions that are attached to the DGPM MOVEMENT EVENTS protocol are VA-specific and of no relevance to non-va facilities, for example, veteran income verification. One common requirement associated with patient movement processing is to update orders, for example to discontinue orders on patient discharge or reinstate orders when a discharge is cancelled (within a given time frame). To process orders updates on patient movements, attach the item OR GUA EVENT PROCESSOR to the SISIA MOVEMENT EVENTS protocol. Other protocols may be required for pharmacy, e.g. PSJ OR PAT ADT, or for dietetics, or etc. In addition to inpatient movement events, the ADT Filer also includes extended action protocols for outpatient events SISIA OUTPATIENT EVENTS, appointment events SISIA APPOINTMENT EVENTS, and update events SISIA UPDATE EVENTS. These work in the same way as the movement events protocol. Update events are processed after ADT-A08 messages (and ADT-A04, if the parameter SISI A04 PROCESS UPDATE EVENTS is valued YES). Appointment events are processed following SIU event messages. Outpatient events are processed when patient class (PV1.2) = O. Note that patient class may be a translated value. Finally, the ADT Filer includes another extended action protocol that may be of interest in selected outpatient interface contexts SISIA PERSON INFORMATION EVENTS. This protocol executes actions for events A28 A31. While the ADT Filer extended action protocols normally execute standard VistA actions, it is also possible to create and attach custom actions to these protocols. This is yet another way in which the ADT Filer may be configured to meet the unique requirements of particular implementation. User-defined action protocols that attach to ADT Filer extended action protocols must not cause any MUMPS error, as this would stop the interface, when single-threaded event processing is in effect. By the same token, user protocols must not attempt to change the resource device in the ADT Filer s processing environment. Of course, a configuration-specific protocol may detach its processing, thereby gaining the freedom to modify the environment. 67

68 Custom Post-event Example Suppose it is desired to file data to the NARRATIVE field of the PHARMACY PATIENT file, after an inpatient admission movement. For the purpose of this example, it will be assumed that the narrative is found in HL7 field ZZA.1, which segment is included in the ADT-A01 message ZZA This is a test narrative Step 1. Create a routine to file the data, for example ZZPMV ;SIS/LM - Miscellaneous patient movement events - July 29, 2010 ;;1.0;MISCELLANEOUS;;August 24, 2009 ; Q PPNAR ;Pharmacy patient narrative ; From protocol ZZ PHARMACY PATIENT NARRATIVE ; N ZZIENS S ZZIENS=$G(SISIDFN,$G(DFN))_"," Q:'(ZZIENS>0) ;File 55 IEN (DFN) N ZZTEXT S ZZTEXT=$G(@SISIPMSG@("ZZA",1)) Q:'$L(ZZTEXT) ;Narrative text S:ZZTEXT="""""" ZZTEXT="@" ;Translate HL7 delete to Fileman delete ; Additional translation here (if needed) N ZZFDA S ZZFDA(55,ZZIENS,1)=ZZTEXT D FILE^DIE(,$NA(ZZFDA)) Q Note that the ZZ* routine and variable names adhere to the VA convention for local development (i.e. development that does not have an assigned namespace). Step 2. Create a PROTOCOL (File 101) entry using the Fileman Enter or Edit File Entries option. NAME: ZZ PHARMACY PATIENT NARRATIVE ITEM TEXT: File Pharmacy Patient Narrative TYPE: action CREATOR: MILLIGAN,LLOYD DESCRIPTION: This protocol may be added as an ITEM on the SISIA MOVEMENT EVENTS protocol to file data to the NARRATIVE field of the PHARAMACY PATIENT file. ENTRY ACTION: D PPNAR^ZZPMV TIMESTAMP: 61936,28967 Step 3. Attach protocol ZZ PHARMACY PATIENT NARRATIVE as an ITEM on the SISIA MOVEMENT EVENTS protocol, with a SEQUENCE number greater than the sequence assigned to the PSJ OR PAT ADT protocol item. 68

69 Select PROTOCOL NAME: SISIA MOVEMENT EVENTS Select ITEM: PSJ OR PAT ADT// ZZ PHARMACY PATIENT NARRATIVE MNEMONIC: SEQUENCE: 200 MODIFYING ACTION: FORMAT CODE: DISPLAY NAME: PROMPT: DEFAULT: HELP: MODE: Select ITEM: Step 4. Create and transmit a test message to register and admit a new inpatient. Be sure to include the HL7 segment that has the narrative data to be filed (segment ZZA in the example). Verify that the narrative was filed. Use Fileman Inquire to File Entries option. Ignore the 0 entries report, if displayed and enter the test patient s name. OUTPUT FROM WHAT FILE: PATIENT MOVEMENT// 55 PHARMACY PATIENT (0 entries) Select PHARMACY PATIENT NAME: <TEST PATIENT NAME> P **Pseudo SSN** NO NON-VETERAN (OTHER) ANOTHER ONE: STANDARD CAPTIONED OUTPUT? Yes// (Yes) Include COMPUTED fields: (N/Y/R/B): NO// - No record number (IEN), no Computed Fields NUMBER: <DFN> NARRATIVE: This is a test narrative NAME: <TEST PATIENT NAME> 69

70 Purge Exceptions Scheduled Option The ADT Filer includes an option that can be scheduled to purge the SISIADT EXCEPTION file. If the LOG STATUS parameter is set to VERBOSE or VERY VERBOSE in a high message volume interface environment, the exception file may accumulate many thousands of entries. Note that it is recommended to set LOG STATUS to NORMAL in the VistA / ADT Filer production environment. The parameter SISI DAYS TO KEEP EXCEPTIONS should be set to a value that retains exceptions long enough to troubleshoot problems that may not have been reported until possibly several days or weeks after they occurred. If the purge option is not scheduled, exceptions will be retained indefinitely. 70

71 VistA HL7 Infrastructure Lower Level Protocol and Logical Link: The ADT Filer receives inbound messages and optionally acknowledges the sender through the VistA HL7 infrastructure. While the Filer installation includes an application-specific TCP/IP listener logical link, it is recommended to use the same multi-threaded TCP/IP Listener as other VistA HL7 applications use. Generally the main VistA listener uses port 5000, while the logical link included with the ADT Filer listens on port If no HL7 listener is being used for any purpose prior to installing the ADT Filer, it is recommended to configure and use the multi-threaded port 5000 listener. FOIA VistA includes File 870 entry named LL050VAMC shown below: 12 NODE: LL050VAMC LLP TYPE: TCP DEVICE TYPE: Multi-threaded Server AUTOSTART: Enabled QUEUE SIZE: 10 TCP/IP PORT: 5000 TCP/IP SERVICE TYPE: MULTI LISTENER PERSISTENT: NO This entry may serve as a template or be renamed. Substitute the implementation s station number for 050 and facility type (e.g. CIVH) for VAMC. 13 The name will have the same form as LL050VAMC, perhaps LL999CIVH or etc. Alternatively the Filer s included single-threaded port 1572 listener may be used: NODE: SISIA_TCP LLP TYPE: TCP DEVICE TYPE: Single-threaded Server STATE: Idle QUEUE SIZE: 10 TCP/IP PORT: 1572 TCP/IP SERVICE TYPE: SINGLE LISTENER If the designated port is unavailable change the value to one that is available. HL7 Application Parameter: The ADT Filer includes one HL7 Application Parameter, which doubles as both sender and receiver. NAME: SISIADT FILER ACTIVE/INACTIVE: ACTIVE FACILITY NAME: SEA ISLAND SYSTEMS COUNTRY CODE: US HL7 ENCODING CHARACTERS: ^~\& HL7 FIELD SEPARATOR: The external system s ADT sender will have a different application name. Therefore, a new HL7 Application Parameter should be created, and the ADT Filer s event driver protocols SENDING APPLICATION fields re-pointed to the new parameter. Since different installations of the ADT Filer involve different sending systems, it is not possible for the ADT Filer KID distribution to include the appropriate application name for each foreign system. However, the Filer can be used as distributed by configuring an interface engine to specify SISIADT FILER for both sending and receiving application names in the message header segment (MSH.3 and MSH.5). 12 Recent FOIA VistA databases replace the LL050VAMC logical link with one named LISTENER. These paragraphs should be considered as general guidance rather than exact descriptions. 13 The API $$SITE^VASITE may be used to ascertain the assigned station number. 71

72 VistA HL7 resolves the application processing routine from four elements of the received message header (MSH): SENDING APPLICATION, MESSAGE TYPE, EVENT TYPE, and HL7 VERSION ID. These message header fields are crossreferenced in the PROTOCOL file, index AHL1. RPMS (the Indian Health Service adaptation of VistA) omits the HL7 VERSION ID subscript from this index. Therefore, when configuring the ADT Filer for an RPMS implementation, it is necessary to modify at least one of the PROTOCOL field DD s to set the AHL1 cross-reference in the VistA way, i.e., to include the HL7 VERSION ID subscript. To configure the included SISIADT FILER application parameter, change the FACILITY NAME field to an appropriate value for the installation site. Some external systems may use a different HL7 field separator or different encoding characters than those specified in the SISIADT FILER application definition. If so, enter the characters in the appropriate HL7 Application Parameter definition (either the SISIADT FILER parameter that is exported with the ADT Filer, or one that has been defined as the sending application in the Filer s event driver protocols). Note that ^ is Fileman s field delimiting character, and therefore cannot be entered as an encoding character using the normal Fileman edit or screen edit process. Instead, if ^ will be used as an HL7 field separator (or encoding character) it is necessary to set the value directly using the MUMPS set command. If variable DA represents the HL7 APPLICATION PARAMETER internal entry number, SET ^HL(771,DA,"FS ") or ^HL(771,DA,"EC ") equal to the field separator or encoding character string that includes the ^ character. In the following illustration, the HL7 APPLICATION PARAMETER is IEN

73 VistA HL7 Infrastructure Basics: In most cases, HL7 will have been configured on the VistA system prior to installing the ADT Filer. However, if no other HL7 applications are in use, it may be necessary to configure and test the VistA HL7 Infrastructure. First use the HL7 Main Menu option, Site Parameter Edit sub-option to verify and modify as necessary the HL7 Site Parameters. It is recommended to set the Days to Keep Completed Messages parameter to at least 30 for troubleshooting purposes. Next use the Filer and Link Management Options to start the HL7 background processes, Link Manager, Default Filers and the listener logical link. It is assumed that Taskman has already been configured and is running. The Systems Link Monitor option may be used to verify the status of HL7 background processes, for example: Incoming filers running => 1 Outgoing filers running => 1 Taskman running Link Manager running If not previously used, the inbound message listener logical link (usually port 5000) will not appear in the NODE column of the Systems Link Monitor display until one or more HL7 messages have been received. Once message activity has commenced the logical link should indicate a status similar to the following: MESSAGES MESSAGES MESSAGES MESSAGES DEVICE NODE RECEIVED PROCESSED TO SEND SENT TYPE STATE LL999CIV MS 0 server 73

74 ADT Filer Routines and Entry Points Alphabetic Listing ROUTINE NAME TAG TYPE BRIEF DESCRIPTION SISIA081 PNAME UPDATE PATIENT NAME ADT UPDATE ADMISSION OR VISIT DATE/TIME ADTI UPDATE INPATIENT ADMISSION DATE/TIME ADTO UPDATE OUTPATIENT ADMISSION DATE/TIME DSC UPDATE DISCHARGE DATE/TIME DSCO NOT SUPPORTED UPDATE OUTPATIENT CHECK/OUT DATE/TIME DSCI UPDATE INPATIENT DISCHARGE DATE/TIME LOCI UPDATE INPATIENT LOCATION LOCO UPDATE OUTPATIENT LOCATION MRN UPDATE MEDICAL RECORD NUMBER SSN UPDATE SOCIAL SECURITY NUMBER (SSN) PHY UPDATE PROVIDER FIELDS IPHY UPDATE INPATIENT PROVIDER FIELDS FILE WRAP FILE~DIE Q QUIT 74

75 SISIA082 WARD UPDATE WARD LOCATION RMBD UPDATE ROOM-BED AVS UPDATE ADMISSION MOVEMENT VISIT FILE ENTRY FTS UPDATE FACILITY TREATING SPECIALTY UPDFTS UPDATE FACILITY TREATING SPECIALTY LMTYP MAS MOVEMENT TRANSACTION TYPE FOR LAST PRECEDING MOVEMENT SAME ACCOUNT FILE WRAP FILE~DIE Q QUIT SISIA083 XFDDEF NOT SUPPORTED EXCLUDE FROM FACILTIY DIRECTORY DEFAULT SISIA47 A47 SUPPORTED API PARTIAL IMPLEMENTATION OF ADT-A47 CHANGE PATIENT IDENTIFIER SISIAA10 A10 NOT SUPPORTED PROCESS RECEIVED ADT-A10 PATIENT ARRIVING EVENT ISAPPT RETURN TRUE IF AND ONLY IF PATIENT HAS APPOINTMENT FOR DATE/TIME ISVIST RETURN TRUE IF AND ONLY IF PATIENT HAS VISIT FOR DATE/TIME SISIAACK MSA NOT SUPPORTED GENERATE ACKNOWLEDGEMENT MESSAGE AFTER PROCESSING EVENT GENACK GENERATE ACKNOWLEDGEMENT MESSAGE AFTER TASKING EVENT SISIABAR EN EVENT PROTOCOL PROCESS RECEIVED HL7 BAR MESSAGE P01 PRE-PROCESS BAR-P01 EVENT 75

76 P05 PRE-PROCESS BAR-P05 EVENT QUIT CLEANUP AND EXIT SISIACCT EN ADD TRANSACTION TO ACCOUNT NUMBER FILE PAT ADD PATIENT POINTER TO TOP LEVEL OF ACCOUNT NUMBER FILE DFN COMPUTE DFN BASED UPON PATIENT ACCOUNT NUMBER FILE FILE TRANSACTION CONTROL ID MULTIPLE FIELD VALUE ADT RETURN INPATIENT ADMISSION DATE/TIME FOR CURRENT ACCOUNT OADT RETURN OUTPATIENT ADMISSION (VISIT) DATE/TIME FOR CURRENT ACCOUNT ADMIEN RETURN INPATIENT ADMISSION MOVEMENT IEN FOR CURRENT ACCOUNT VISIT RETURN OUTPATIENT VISIT IEN FOR CURRENT ACCOUNT SCHIEN RETURN INPATIENT SCHEDULED ADMISSION IEN FOR CURRENT ACCOUNT EIEN RETURN LAST PREVIOUS TRANSACTION IEN OF SPECIFIED EVENT TYPE FOR CURRENT ACCOUNT DSCI RETURN LAST PREVIOUS INPATIENT DISCHARGE FOR CURRENT ACCOUNT PREVXA RETURN LAST TRANSFER OR ADMISSION PRECEDING A SPECIFIED PATIENT MOVEMENT LPMDA LAST PREVIOUS PATIENT MOVEMENT OF ANY TYPE FOR CURRENT ACCOUNT DEL DELETE POINTERS TO SPECIFIED PATIENT MOVEMENT FROM CURRENT ACCOUNT ACCT RETURN ACCOUNT ASSOCIATED WITH SPECIFIED PATIENT MOVEMENT OR VISIT CUR RETURN TRUE IF AND ONLY IF CURRENT ADMISSION BELONGS TO CURRENT ACCOUNT PTYPE RETURN PATIENT TYPE FOR CURRENT ACCOUNT SAMEACCT RETURN TRUE IF AND ONLY IF SPECIFIED MOVEMENT BELONGS TO CURRENT ACCOUNT 76

77 SISIACPR EN PUBLIC DISPLAY ADT FILER COPYRIGHT MESSAGE DATA TEXT OF COPYRIGHT NOTICE SISIADBA LXFR LAST (CURRENT) TRANSFER MOVEMENT XPMIEN ADMISSION MOVEMENT MATCHING DFN AND ADMISSION DATE/TIME XVSIEN VISIT (IEN) MATCHING DFN AND VISIT DATE/TIME CN RETURN $NAME OF "CN" NODE REFERRING TO DFN OR MOVEMENT KCN DELETE "CN" NODES RELATING TO SPECIFIED ADMISSION MOVEMENT ARM UPDATE "ARM" CROSS-REFERENCE DUPCHK DUPLICATE MOVEMENT CHECK XDOK VALIDITY CHECKS FOR TRANSFER OR DISCHARGE EVENTS UNWIND POST-EVENTS FOR VARIOUS CATEGORIES OF MESSAGE EVENT SISIADFN ADFN PUBLIC RETURN DFN FOR CURRENT ACCOUNT NUMBER CDFN PUBLIC RETURN RESULT OF COMPUTE DFN CODE IN MAIN PARAMETER FILE CDFN2 PUBLIC RETURN RESULT OF PATIENT (2) DFN CODE IN MAIN PARAMETER FILE CDFN3 PUBLIC RETURN RESULT OF CHANGE PPID DFN CODE IN MAIN PARAMETER FILE ACDFN PUBLIC RETURN ACCOUNT NUMBER DFN IF IT EXISTS, ELSE RETURN COMPUTE DFN VALUE PSEUDFN RETURN COMPUTE DFN FOR A PSEUDO PID SEGMENT (NOT CURRENT MESSAGE PID) IID RETURN INTERNAL PATIENT ID OR LIST OF IDs FROM PID.3 XID RETURN EXTERNAL PATIENT ID OR LIST OF IDs FROM PID.2 77

78 PPID WRAP $$PPID~SISIADT4 - RETURN MESSAGE PPID AS DEFINED BY THE PPID FIELD MAP VPID RETURN VISTA PPID FOR THE GIVEN DFN AS DEFINED BY THE PPID FIELD MAP FILEPPID FILE ONE PRIMARY PATIENT ID USING THE PPID AUXILIARY FIELD MAP FILEHRN FILE HEALTH RECORD NO. IN IHS PATIENT FILE XFILEPID EXTRINSIC FUNCTION WRAPPER ON FILEPPID~SISIADFN XFILEHRN EXTRINSIC FUNCTION WRAPPER ON FILEHRN~SISIADFN INST RETURN INSTITUTION FILE IEN FROM MSH SENDING FACILITY NAME REG SUPPORTED API IMPLEMENT REGISTER PATIENT SISIADSP CFG OPTION DISPLAY SUMMARY OF CURRENT ADT FILER CONFIGURATION LIC NOT SUPPORTED DISPLAY LICENSE INFORMATION SISIADT SISIADT PUBLIC DISPLAY COPYRIGHT NOTICE EN EVENT PROTOCOL ADT FILER MAIN ENTRY POINT - PROCESS RECEIVED MESSAGE NOTASK PROCESS EVENTS IN VISTA HL7 MESSAGE THREAD DQ CONSOLIDATED ENTRY POINT FOR BRANCHING TO EVENT PROCESSING ROUTINES EVNPRE PRE-EVENT HANDLER PROCESSING EVNFIN FINAL PROCESSING AFTER EVENT AND POST-EVENT PROCESSING IS COMPLETE EXIT FINAL EXIT FROM TASKED EVENT AND POST-EVENT PROCESSING DUZ ESTABLISH USER CONTEXT IF APPLICABLE ACKONLY EVENT PROTOCOL ACKNOWLEDGE AN UNSUPPORTE EVENT MESSAGE NOP DO NOTHING PUBLIC 78

79 TR FILTER ($TRANSLATE) CHARACTERS FROM RECEIVED MESSAGE POST POST-EVENT PROCESSING - CALLS EVENTS~SISIADBA QUIT CLEAR LOCKS, KILL MISCELLANEOUS VARIABLE AND ~UTILITY("DGPM",$J) SISIADT0 A01 PRE-PROCESS RECEIVED ADT-A01 A02 PRE-PROCESS RECEIVED ADT-A02 A03 PRE-PROCESS RECEIVED ADT-A03 A04 PRE-PROCESS RECEIVED ADT-A04 A05 PRE-PROCESS RECEIVED ADT-A05 A06 PRE-PROCESS RECEIVED ADT-A06 A07 PRE-PROCESS RECEIVED ADT-A07 A08 PRE-PROCESS RECEIVED ADT-A08 A10 PRE-PROCESS RECEIVED ADT-A10 A11 PRE-PROCESS RECEIVED ADT-A11 A12 PRE-PROCESS RECEIVED ADT-A12 A13 PRE-PROCESS RECEIVED ADT-A13 A17 PRE-PROCESS RECEIVED ADT-A17 A21 PRE-PROCESS RECEIVED ADT-A21 A22 PRE-PROCESS RECEIVED ADT-A22 A28 PRE-PROCESS RECEIVED ADT-A28 A31 PRE-PROCESS RECEIVED ADT-A31 79

80 A34 PRE-PROCESS RECEIVED ADT-A34 A36 PRE-PROCESS RECEIVED ADT-A36 A47 PRE-PROCESS RECEIVED ADT-A47 UNK PRE-PROCESS RECEIVED UNKNOWN MESSAGE EVENT LOG WRAP EXCEPTION LOGGING FOR EVENT PRE-PROCESSING POST CALL POST~SISIADT TO PROCESS POST EVENTS QUIT CALL QUIT~SISIADT TO CLEAR LOCKS AND VARIABLES SISIADT1 CNCLADM NOT SUPPORTED PROCESS DATA ARRAY THROUGH CANCEL ADMIT EVENT HANDLER ADMIT NOT SUPPORTED PROCESS DATA ARRAY THROUGH ADMIT EVENT HANDLER A01 PROCESS RECEIVED ADT-A01 EVENT (ADMIT PATIENT) A11 PROCESS RECEIVED ADT-A11 EVENT (CANCEL ADMIT) SISIADT2 CNCLXFR NOT SUPPORTED PROCESS DATA ARRAY THROUGH CANCEL TRANSFER EVENT HANDLER TRANSFER NOT SUPPORTED PROCESS DATA ARRAY THROUGH TRANSFER EVENT HANDLER A02 PROCESS RECEIVED ADT-A02 EVENT (TRANSFER PATIENT) A12 PROCESS RECEIVED ADT-A12 EVENT (CANCEL TRANSFER) SISIADT3 CNCLDIS NOT SUPPORTED PROCESS DATA ARRAY THROUGH CANCEL DISCHARGE EVENT HANDLER DISCHARG NOT SUPPORTED PROCESS DATA ARRAY THROUGH DISCHARGE EVENT HANDLER A03 PROCESS RECEIVED ADT-A03 EVENT (DISCHARGE PATIENT) A13 PROCESS RECEIVED ADT-A13 EVENT (CANCEL DISCHARGE) 80

81 CONTINUE CONTINUATION OF DISCHARGE AND CANCEL DISCHARGE EVENT PROCESSING SISIADT4 REGISTER NOT SUPPORTED PROCESS DATA ARRAY THROUGH REGISTER PATIENT EVENT HANDLER A04 PROCESS RECEIVED ADT-A04 EVENT (REGISTER PATIENT) PPID EVALUATE PRIMARY PATIENT ID AUXILIARY FIELD MAP JOIN CONVERT NAME COMPONENTS TO VISTA PATIENT NAME FORMAT HRN FILE PRIMARY PATIENT ID TO HEALTH RECORD NO. IN IHS PATIENT FILE SISIADT5 PREADMIT NOT SUPPORTED PROCESS DATA ARRAY THROUGH ADT-A05 EVENT HANDLER A05 PROCESS RECEIVED ADT-A05 EVENT (PRE-ADMIT PATIENT) CONT CONTINUE PRE-ADMIT EVENT PROCESSING AS VISTA SCHEDULED ADMISSION A14 NOT SUPPORTED PROCESS RECEIVED ADT-A14 EVENT (PENDING ADMIT) A27 NOT SUPPORTED PROCESS RECEIVED ADT-A27 EVENT (CANCEL PENDING ADMIT) A38 PROCESS RECEIVED ADT-A38 EVENT (CANCEL PRE-ADMIT) SISIADT6 A06 PROCESS RECEIVED ADT-A06 EVENT (OUTPATIENT TO INPATIENT) SISIADT7 A07 PROCESS RECEIVED ADT-A07 EVENT (INPATIENT TO OUTPATIENT) SISIADT8 UPDATE NOT SUPPORTED PROCESS DATA ARRAY THROUGH ADT-A08 EVENT HANDLER A08 PROCESS RECEIVED ADT-A08 EVENT (PATIENT INFORMATION UPDATE) PNAME PRE-PROCESS UPDATE PATIENT NAME ADT PRE-PROCESS UPDATE ADMISSION OR VISIT DATE/TIME 81

82 DSC PRE-PROCESS UPDATE DISCHARGE OR CHECK-OUT DATE/TIME LOCI PRE-PROCESS UPDATE INPATIENT LOCATION LOCO PRE-PROCESS UPDATE OUTPATIENT LOCATION MRN PRE-PROCESS UPDATE MEDICAL RECORD NUMBER (MRN) SSN PRE-PROCESS UPDATE SOCIAL SECURITY NUMBER (SSN) PHY PRE-PROCESS UPDATE PROVIDER FIELDS WARD PRE-PROCESS UPDATE INPATIENT WARD LOCATION RMBD PRE-PROCESS UPDATE INPATIENT ROOM-BED LOCATION AVS PRE-PROCESS UPDATE ADMISSION MOVEMENT VISIT FILE ENTRY FTS PRE-PROCESS UPDATE FACILITY TREATING SPECIALTY UPDFTS PRE-PROCESS UPDATE FACILITY TREATING SPECIALTY BEFORE SET "PRIOR" IMAGE OF UPDATED MOVEMENT FOR POST-PROCESSING AFTER SET "AFTER" IMAGE OF UPDATED MOVEMENT FOR POST-PROCESSING LMTYP RETURN MAS MOVEMENT TRANSACTION TYPE OF LAST PRECEDING MOVEMENT FOR ACCOUNT FILE WRAPE FILE~DIE WITH OPTIONAL DIERR EXCEPTION RECORDING Q QUIT SISIADTC OKD COMMON CODE FOR PROCESSING CANCELLED MOVEMENTS (ADAPTED FROM OKD~DGPMV3) APL RESTORE PATIENT TO A DIFFERENT LOCATION FOLLOWING A CANCELLED MOVEMENT APL12 RESTORE PATIENT TO A DIFFERENT LOCATION FOLLOWING A CANCELLED TRANSFER 82

83 SISIADTI EN PROCESS MAPPED FIELDS AFTER EVENT PROCESSING - CALLS ORD~SISIAGU SISIADTK SISIADTK PUBLIC DISPLAY COPYRIGHT NOTICE A01 SENDING APPLICATION-SPECIFIC ADT-A01 EVENT PRE-PROCESSING A02 SENDING APPLICATION-SPECIFIC ADT-A02 EVENT PRE-PROCESSING A03 SENDING APPLICATION-SPECIFIC ADT-A03 EVENT PRE-PROCESSING A04 SENDING APPLICATION-SPECIFIC ADT-A04 EVENT PRE-PROCESSING A05 SENDING APPLICATION-SPECIFIC ADT-A05 EVENT PRE-PROCESSING A06 SENDING APPLICATION-SPECIFIC ADT-A06 EVENT PRE-PROCESSING A07 SENDING APPLICATION-SPECIFIC ADT-A07 EVENT PRE-PROCESSING A08 SENDING APPLICATION-SPECIFIC ADT-A08 EVENT PRE-PROCESSING A10 NOT SUPPORTED SENDING APPLICATION-SPECIFIC ADT-A10 EVENT PRE-PROCESSING A11 SENDING APPLICATION-SPECIFIC ADT-A11 EVENT PRE-PROCESSING A12 SENDING APPLICATION-SPECIFIC ADT-A12 EVENT PRE-PROCESSING A13 SENDING APPLICATION-SPECIFIC ADT-A13 EVENT PRE-PROCESSING A17 NOT SUPPORTED SENDING APPLICATION-SPECIFIC ADT-A17 EVENT PRE-PROCESSING A21 SENDING APPLICATION-SPECIFIC ADT-A21 EVENT PRE-PROCESSING A22 SENDING APPLICATION-SPECIFIC ADT-A22 EVENT PRE-PROCESSING A28 SENDING APPLICATION-SPECIFIC ADT-A28 EVENT PRE-PROCESSING A31 SENDING APPLICATION-SPECIFIC ADT-A31 EVENT PRE-PROCESSING A34 SENDING APPLICATION-SPECIFIC ADT-A34 EVENT PRE-PROCESSING 83

84 A36 NOT SUPPORTED SENDING APPLICATION-SPECIFIC ADT-A36 EVENT PRE-PROCESSING KPC SENDING APPLICATION-SPECIFIC PATIENT CLASS TRANSLATION PREACCT NOT SUPPORTED SENDING APPLICATION-SPECIFIC PLACE HOLDER FOR PATIENT ACCOUNT NUMBER REG SENDING APPLICATION-SPECIFIC PATIENT REGISTRATION WRAPPER INS DOCUMENTATION ONLY SENDING APPLICATION-SPECIFIC GUARANTOR AND INSURANCE INFORMATION PROCESSING POST SENDING APPLICATION-SPECIFIC POST-EVENTS PROCESSING WRAPPER SISIADTL UPDLOC UPDATE INPATIENT LOCATION FOR SPECIAL CASES WIEN COMPUTE/RETURN WARD LOCATION IEN RIEN COMPUTE/RETURN ROOM-BED IEN SISIADTM A28 SENDING APPLICATION-SPECIFIC ADT-A28 EVENT PROCESSING (ADD PERSON INFORMATION) A31 SENDING APPLICATION-SPECIFIC ADT-A31 EVENT PROCESSING (UPDATE PERSON INFO.) REG WRAP A04~SISIADT4 TO CREATE A PATIENT FILE ENTRY FOR A NEW VISTA PATIENT IENS RETURN INSURANCE TYPE SUB-FILE IENS DFN RETURN DFN USING COMPUTE DFN CODE FROM MAIN PARAMETER FILE INST RETURN INSTITUTION FILE IEN USING MSH SENDING FACILITY NAME FMT SPECIAL FORMAT FOR PATIENT OR PROVIDER ID INCLUDING FACILITY PREFIX FILEHRN FILE HEALTH RECORD NO. TO IHS PATIENT FILE CDFN RETURN DFN FROM FACILITY-SPECIFIC HEALTH RECORD NO. MMRN SENDING APPLICATION-SPECIFIC MESSAGE MRN (MEDICAL RECORD NUMBER) 84

85 QUIT KILL MISCELLANEOUS HL AND ADT FILER VARIABLES SISIADTO A01 PROCESS RECEIVED ADT-A01 [OUTPATIENT] EVENT (ADMIT PATIENT) A02 PROCESS RECEIVED ADT-A02 [OUTPATIENT] EVENT (TRANSFER) A03 PROCESS RECEIVED ADT-A03 [OUTPATIENT] EVENT (DISCHARGE) A05 IMPLEMENTATION-SPECIFIC PROCESSING OF ADT-A05 [OUTPATIENT] EVENT (PRE-ADMIT) A11 PROCESS RECEIVED ADT-A11 [OUTPATIENT] EVENT (CANCEL ADMIT) A12 NOT SUPPORTED PROCESS RECEIVED ADT-A12 [OUTPATIENT] EVENT (CANCEL TRANSFER) A13 PROCESS RECEIVED ADT-A13 [OUTPATIENT] EVENT (CANCEL DISCHARGE) VLOC RETURN VISIT LOCATION USING COMPUTE VISIT LOCATION CODE IN PARAMETER FILE SISIADTS V31 CREATE SPECIALTY TRANSFER MOVEMENT AND PTF FILE ENTRY SPEC CREATE SPECIALTY TRANSFER MOVEMENT SPECQ EXIT SPECIALTY TRANSFER PROCESSING NEW WRAP NEW~DGPMV36 - NEW SPECIALTY TRANSFER MOVEMENT EDIT SIMULATE [DGPM SPECIALTY TRANSFER] INPUT TEMPLATE PROCESSING FILE NON-INTERACTIVE REPLACEMENT FOR [DGPM SPECIALTY TRANSFER] WITH DEFAULT VALUES SISIADTT SISIADTT NOT SUPPORTED SCRIPT-BASED EVENT PROCESSING SISIADTX A36 NOT SUPPORTED PROCESS RECEIVED ADT-A36 EVENT (MERGE PATIENT INFORMATION) XM CREATE AND SEND AN MESSAGE 85

86 SISIAEDT AUX OPTION ENTER/EDIT AUXILIARY FIELD MAP SISIAENV SISIAENV KIDS USE ONLY ENVIRONMENT CHECKS UPGRADE KIDS USE ONLY ENVIRONMENT CHECK FOR ADT FILER VERSION 2.0 UPGRADE 1 KIDS USE ONLY ADT FILER VERSION 2.0 PATCH 1 ENVIRONMENT CHECK VER RETURN INSTALLED ADT FILER VERSION CKVR RETURN RESULT OF ADT FILER VERSION CHECK COMPARISON CKPL RETURN RESULT OF ADT FILER PATCH LIST COMPARISON W1 KIDS USE ONLY ISSUE 'PATCH OUT-OF-SEQUENCE' WARNING SISIAEX SWAP SUPPORTED API PROCESS ADT-A17 EVENT (SWAP PATIENTS SUPPORTED API) LOG LOG A GENERIC EXCEPTION WITH FAILURE CODE SISIAGEN EN INTERACTIVELY AUTO-GENERATE EVENT-DRIVER/SUBSCRIBER PROTOCOL PAIRS EVN CALLED BY EN~SISIAGEN TO FILE PROTOCOLS C CALLED BY EVN~SISIAGEN TO POPULATE CLIENT PROTOCOL FILE DESCRIPTOR ARRAY S CALLED BY EVN~SISIAGEN TO POPULATE SERVER PROTOCOL FILE DESCRIPTOR ARRAY NAME CONSTRUCT STANDARD ADT FILER EVENT PROTOCOL NAME ITXT CONSTRUCT STANDARD ADT FILER EVENT PROTOCOL TEXT DESC CONSTRUCT STANDARD ADT FILER EVENT PROTOCOL DESCRIPTION SISIAGT1 IB ACTION PROTOCOL IMPLEMENTS SISIA GT1 TO IB SPONSOR PROTOCOL 86

87 RPMS ACTION PROTOCOL IMPLEMENTS SISIA GT1 TO RPMS GUARANTOR PROTOCOL API ACTION PROTOCOL IMPLEMENTS SISIA GT1 USE IMPL-SPECIFIC API PROTOCOL RELDA LOOKUP AND RETURN SPONSOR RELATIONSHIP FILE IEN SISIAGU ONE PROCESS ONE ENTRY IN SISIADT AUXILIARY FIELD MAP FILE ORD PROCESS AUXILIARY FIELD MAP ENTRIES IN SPECIFIED ORDER PROCESS FROM ORD~SISIAGU PROCESS AUXILIARY FIELD MAPS P GENERALIZATION OF MUMPS $PIECE FUNCTION SA RETURN SENDING APPLICATION IEN FOR EVENT DRIVER PROTOCOL FS RETURN HL7 FIELD SEPARATOR FOR PROTOCOL'S SENDING APPLICATION EC RETURN HL7 ENCODING CHARACTERS FOR PROTOCOL'S SENDING APPLICATION CKIENS SYNTAX-CHECK AUXILIARY FIELD MAP IENS FORMAT AND VALUE SISIAINS EN ACTION PROTOCOL IMPLEMENTS SISIA FILE INSURANCE DATA PROTOCOL INS FROM EN~SISIAINS - PROCESS IN1 INSURANCE INFORMATION SEGMENT GT01 SENDING APPLICATION-SPECIFIC GT1 SEGMENT PROCESSING TO IHS GUARANTOR FILE GUARN SUB-PROCESSING OF SENDING APPLICATION-SPECIFIC GT1 SEGMENT MCAR SUB-PROCESSING OF SENDING APPLICATION-SPECIFIC MEDICARE DATA MCAID SUB-PROCESSING OF SENDING APPLICATION-SPECIFIC MEDICAID DATA OTHER SUB-PROCESSING OF SENDING APPLICATION-SPECIFIC INSURANCE DATA PRVNS SUB-PROCESSING OF SENDING APPLICATION-SPECIFIC INSURANCE AND HMO DATA 87

88 TYPE RETURN INSURANCE TYPE GIVEN IHS INSURANCE COMPANY NAME STATE RETURN INSURER STATE GIVEN IHS INSURANCE COMPANY NAME NIEN LOOKUP INSURANCE COMPANY NAME AND RETURN IHS FILE IEN SISIAMSC A17 SUPPORTED API IMPLEMENTS SWAP PATIENTS A17 SUPPORTED API A21 PROCESS ADT-A21 EVENT (BEGIN LEAVE OF ABSENCE) A22 PROCESS ADT-A22 EVENT (END LEAVE OF ABSENCE) A34 SUPPORTED API IMPLEMENTS MERGE PATIENT INFORMATION SUPPORTED API SISIAP01 P01 EVENT PROTOCOL SENDING APPLICATION-SPECIFIC BAR-P01 MESSAGE EVENT HANDLER ID RETURN ARRAY OF IDENTIFIERS FROM BAR MESSAGE PID SEGMENT AA RETURN ARRAY OF ASSIGNING AUTHORITIES FROM BAR MESSAGE PID SEGMENT INST RETURN INSTITUTION FILE IEN FOR NAME-MEANINGFUL INSTITUTION CDFN NOT SUPPORTED FOR BACKWARD COMPATIBILITY - COMPUTE DFN IN APPLICATION-SPECIFIC WAY DFN FROM CDFN~SISIAP01 - IMPLEMENTATION-SPECIFIC PATIENT LOOKUP FILEID IMPLEMENTATION-SPECIFIC FILE PATIENT IDENTIFIERS CFILEID FROM FILEID~SISIAP01 SISIAP05 / SISIAP51 P05 IMPLEMENTATION-SPECIFIC BAR-P05 EVENT PROCESSING UPDAID IMPLEMENTATION-SPECIFIC PATIENT ID UPDATE UPRQID IMPLEMENTATION-SPECIFIC PATIENT FILE REQUIRED IDENTIFIERS UPDATE UPDATE ACTION PROTOCOL IMPLEMENTS SISIA GENERIC UPDATE PROTOCOL 88

89 NK NEXT OF KIN UPDATE PROCESSING EC EMERGENCY CONTACT UPDATE PROCESSING E2 SECONDARY EMERGENCY CONTACT K2 SECONDARY NEXT OF KIN UPDATE PROCESSING DD D-DESIGNEE EM EMPLOYER UPDATE PROCESSING DELFLDS DELETE SELECTED PATIENT FIELDS DELNOK DELETE NEXT-OF-KIN FIELDS DELINS DELETE INSURANCE TYPE MULTIPLE SUB-ENTRIES FOR PATIENT RACEINFO FILE RACE INFORMATION MULTIPLE IN PATIENT FILE DELRACE DELETE RACE INFORMATION MULTIPLE SUB-ENTRIES FOR PATIENT FILE ADDRESS FROM REPETITIONS OF SEQ PID.13 SISIAPI GETX PUBLIC RETURN LAST PREVIOUS TRANSACTION IEN REFERENCING MOVEMENT OR VISIT ACCT RETURN ACCOUNT IEN~NAME FOR PATIENT x DATE/TIME x CLASS ACCOUNT PUBLIC RETURN ACCOUNE IEN~NAME FOR PATIENT x DATE/TIME x [MOVEMENT IEN OR VISIT IEN] NEWACCT DEVELOPMENT USE ONLY TEST ACCOUNT NUMBER API VERIFY PUBLIC VERIFY ACCOUNT-PATIENT XACCT PUBLIC RETURN EXTERNAL ACCOUNT NUMBER FOR ACCOUNT (DEFAULT=CURRENT ACCOUNT) SISIAPNS EN FROM UPDATE~SISIAP05 - UPDATE PATIENT INSURANCE TYPE SUB-FILE ENTRIES INS FROM EN~SISIAPNS - CONTINUATION OF INSURANCE TYPE MULTIPLE UPDATE 89

90 GUARN CONDITIONALLY PROCESS GUARANTOR DATA AS INSURANCE TYPE MULTIPLE CONT CONTINUATION OF INSURANCE PROCESSING TO INSURANCE TYPE MULTIPLE NIEN RETURN INSURER IEN FROM VISTA INSURANCE COMPANY FILE LOOKUP (FILE 36) TYPE NOT SUPPORTED RETURN EMPTY STRING LAYGO CREATE NEW INSURANCE COMPANY FILE ENTRY (FILE 36) AND RETURN IEN GNS CONSTRUCT PSEUDO IN1 and IN2 SEGMENT DATA FROM GUARANTOR (GT1) SEGMENT DATA DELALL DELETE INSURANCE TYPE MULTIPLE ENTRIES FOR PATIENT SISIAPPT EN EVENT PROTOCOL VISTA SIU MESSAGE EVENT PROCESSING S12 IMPLEMENTATION-SPECIFIC MAKE APPOINTMENT EVENT S13 IMPLEMENTATION-SPECIFIC RESCHEDULE APPOINTMENT S14 IMPLEMENTATION-SPECIFIC MODIFY APPOINTMENT S15 IMPLEMENTATION-SPECIFIC CANCEL APPOINTMENT S17 IMPLEMENTATION-SPECIFIC DELETE APPOINTMENT S26 IMPLEMENTATION-SPECIFIC APPOINTMENT NO SHOW POST UNWIND SISIA APPOINTMENT EVENTS EXTENDED ACTION PROTOCOL QUIT WRAP QUIT~SISIADT SISIAPRE EN KIDS USE ONLY PRE-INSTALL MAIN ENTRY FOR ALL VERSIONS TWOP0 KIDS USE ONLY PRE-INSTALL FOR VERSION 2.0 CVT CONVERT VERSION STRING TO ROUTINE TAG TWOUPG KIDS USE ONLY 90

91 VERSION 2.0 UPGRADE PRE-INSTALL PSSN CLEANUP DEPRECATED SISIADT PSEUDO-SSN FILE DELFILE DELETE ONE DEPRECATED ADT FILER FILE DIK WRAP ~DIK SISIAPRT TRHIST OPTION IMPLEMENTS SISIADT TRANSACTION CHRONOLOGY OPTION XCPT OPTION IMPLEMENTS SISIADT PRINT EXCEPTIONS OPTION SISIAPST EN KIDS USE ONLY POST-INSTALL ENTRY P34 KIDS USE ONLY PATCH 1.8*34 POST-INSTALL TWOP0 KIDS USE ONLY VERSION 2.0 POST-INSTALL TWOPAT3 KIDS USE ONLY VERSION 2.0 PATCH 3 POST-INSTALL TWOPAT6 KIDS USE ONLY VERSION 2.0 PATCH 6 POST-INSTALL TWOPAT8 KIDS USE ONLY VERSION 2.0 PATCH 8 POST-INSTALL TWOPAT10 KIDS USE ONLY VERSION 2.0 PATCH 10 POST-INSTALL TWOPAT12 KIDS USE ONLY VERSION 2.0 PATCH 12 POST-INSTALL TWOPAT14 KIDS USE ONLY VERSION 2.0 PATCH 14 POST-INSTALL TWOPAT16 KIDS USE ONLY VERSION 2.0 PATCH 16 POST-INSTALL ADDPP ADD EVENT-DRIVER / SUBSCRIBER PROTOCOL PAIR DQ2P14 KIDS USE ONLY BACKGROUND PART OF VERSION 2.0 PATCH 14 POST-INSTALL DPTINP PUBLIC VERSION 2.0 PATCH 12 ONE-TIME CLEANUP OF NULL-VALUED INPATIENT FIELDS IN FILE 2 DPTINPQ OPTIONAL TASKED ENTRY POINT FOR ONE-TIME CLEANUP OF INPATIENT FIELDS IN FILE 2 91

92 LCI OPTION RETURN LAST COMPLETED ADT FILER PATCH IN ORDER OF INSTALL COMPLETE TIME CVT CONVERT VERSION STRING TO ROUTINE TAG RNPROT RENAME PROTOCOLS (PART OF VERSION 2.0 UPGRADE) RENAME FROM RNPROT~SISIAPST - RENAME ONE PROTOCOL PROTOCOL DATA BLOCK PROTOCOL LIST IN OLD NAME~NEW NAME FORMAT SISIARP1 XDETAILS REMOTE PROCEDURE IMPLEMENTS RPC SISIADT TRANSACTION DETAILS SUMMARY REMOTE PROCEDURE IMPLEMENTS RPC SISIADT PATIENT SUMMARY APPEND FROM SUMMARY~SISIAPR1 - APPEND DATA TO ACCOUNT SUMMARY ACCOUNT REMOTE PROCEDURE IMPLEMENTS RPC SISIADT GET ACCOUNT SISIARPC XCPT REMOTE PROCEDURE IMPLEMENTS RPC SISIADT EXCEPTIONS LIST MSG REMOTE PROCEDURE IMPLEMENTS RPC SISIADT MESSAGE FLD REMOTE PROCEDURE IMPLEMENTS RPC SISIADT HL7 FIELD TBLST REMOTE PROCEDURE IMPLEMENTS RPC SISIADT TABLE LIST TBL REMOTE PROCEDURE IMPLEMENTS RPC SISIADT TABLE CONTENTS HL7 REMOTE PROCEDURE IMPLEMENTS RPC SISIADT HL7 STATUS GETCFG REMOTE PROCEDURE IMPLEMENTS RPC SISIADT GET CONFIGURATION PUTCFG NOT SUPPORTED PLANNED RPC TO FILE CONFIGURATION DATA GETONE REMOTE PROCEDURE IMPLEMENTS RPC SISIADT GET ONE FIELD GETALL REMOTE PROCEDURE IMPLEMENTS RPC SISIADT GET ALL FIELDS PROTLIST REMOTE PROCEDURE 92

93 IMPLEMENTS RPC SISIADT PROTOCOL LIST AUXMLIST REMOTE PROCEDURE IMPLEMENTS RPC SISIADT AUXILIARY MAP LIST FLIST REMOTE PROCEDURE IMPLEMENTS RPC SISIADT FRIENDS LIST FILE REMOTE PROCEDURE IMPLEMENTS RPC SISIADT FILE DATA PLIST REMOTE PROCEDURE IMPLEMENTS RPC SISIADT PATIENT ACCOUNT LIST ALIST REMOTE PROCEDURE IMPLEMENTS RPC SISIADT ONE ACCOUNT LIST PNAME REMOTE PROCEDURE IMPLEMENTS RPC SISIADT PATIENT NAME SISIAS12 S12 PROCESS SIU-S12 MAKE APPOINTMENT AS VISTA VISIT ENTRY DATA2PCE WRAPS $$DATA2PCE~PXAPI TO CREATE A VISIT PROT FILE VISIT POINTER AND EXTERNAL EVENT ID TO ACCOUNT NUMBER TRANSACTION MULTIPLE SISIAS14 S14 DEFINE VARIABLES AND CALL AUXILIARY FIELD MAP PROCESSING TO MODIFY APPOINTMENT PR QUIT NOT SUPPORTED SISIAS15 S15 PROCESS CANCELLED APPOINTMENT AS DELETED VISIT PROT QUIT NOT SUPPORTED SISIASIH TOASIH IMPLEMENTATION-SPECIFIC TO ABSENT SICK IN HOSPITAL (FROM LONG TERM CARE) FRASIH IMPLEMENTATION-SPECIFIC FROM ABSENT SICK IN HOSPITAL (TO LONG TERM CARE) WHASIH IMPLEMENTATION-SPECIFIC DISCHARGE WHILE ABSENT SICK IN HOSPITAL LASTLTC RETURN MOST RECENT LONG-TERM CARE ADMISSION ASSOCIATES WITH AN ASIH TRANSFER LASTHOSP RETURN MOST RECENT ACUTE CARE ADMISSION 93

94 PSEUDO RETURN PSEUDO-DISCHARGE (FUTURE) MOVEMENT IEN FOR PATIENT x ADMISSION ISACCT RETURN TRUE IF AND ONLY IF ADMISSION MOVEMENT IEN BELONGS TO CURRENT ACCOUNT ISTOASIH EXECUTE 'TO ASIH' MUMPS CODE IN MAIN PARAMETER FILE ISASIH RETURN TRUE IF AND ONLY IF PATIENT IS CURRENTLY ASIH (FILE 405 FIELD.22) SISIASIU EN EVENT PROTOCOL PROCESS VISITA SIU-EVN MESSAGES S12 PRE-PROCESS SIU-S12 MAKE APPOINTMENT S13 PRE-PROCESS SIU-S13 RESCHEDULE APPOINTMENT S14 PRE-PROCESS SIU-S14 MODIFY APPOINTMENT S15 PRE-PROCESS SIU-S15 CANCEL APPOINTMENT PROT STAGE EVENT PROCESSING CODE FOR SIU-S12, -S14, and -S15 VISIT RETURN VISIT IEN ASSOCIATED WITH AN EXTERNAL EVENT ID, SUCH AS SENDER'S APPT ID QUIT CALL POST-APPOINTMENT EVENTS AND QUIT~SISIADT SISIAT12 S12 SUPPORTED API PREPARE VARIABLES AND CALL MAKE APPOINTMENT SUPPORTED API MAKE WRAP CALL TO X~SISIAX SISIAT13 S13 SUPPORTED API CALL RESCHEDULE APPOINTMENT SUPPORTED API RESCHED WRAP CALL TO X~SISIAX SISIAT14 S14 SUPPORTED API CALL MODIFY APPOINTMENT SUPPORTED API MODIFY WRAP CALL TO X~SISIAX 94

95 SISIAT15 S15 SUPPORTED API CALL CANCEL APPOINTMENT SUPPORTED API CANCEL WRAP CALL TO X~SISIAX SISIAT17 S17 CONDITIONALLY PROCESS SIU-S17 (DELETE APPOINTMENT) AS -S15 (CANCEL APPOINTMENT) SISIAT26 S26 CONDITIONALLY PROCESS SIU-S26 (APPOINTMENT NO SHOW) AS -S15 (CANCEL APPT) SISIATST CAPTURE DEVELOPMENT USE ONLY CAPTURE AN INCOMING MESSAGE RESTORE DEVELOPMENT USE ONLY RESTORE A MESSAGE FOR TESTING TEST DEVELOPMENT USE ONLY RUN FOREGROUND TEST FOR DEVELOPMENT/DEBUG ONLY MSG OPTION IMPLEMENTS OPTION SISIADT MESSAGE DISPLAY. SHOW HL7 MESSAGE VIA INTERACTIVE DEV. FIRST RETURNS FIRST FILE 773 IEN CORRESPONDING TO NON=UNIQUE MESSAGE CONTROL ID LAST RETURNS LAST 773 IEN CORRESPONDING TO NON=UNIQUE MESSAGE CONTROL ID MSGOPT OPTION IMPLEMENTS VISTA HL7 MESSAGE DISPLAY OPTION. WRAPS MSG~SISIATST SEND PUBLIC SEND HOST FILE AS HL7 MESSAGE FOR TESTING SISIAUDT EN1 ACTION PROTOCOL IMPLEMENTS SISIA MISCELLANEOUS ACTIONS PROTOCOL F405 FILE ADT FILER REFERENCE SUB-FIELDS TO PATIENT MOVEMENT FILE ENTRY XACCT CONVERT ACCOUNT~TRANSACTION TO EXTERNAL FORMAT SISIAUNS SURE PUBLIC CONDITIONALLY UNINSTALL THE ADT FILER - REQUIRES SECURITY KEY ONEBLD 95

96 FROM SURE~SISIAUNS - REMOVE ADT FILER COMPONENTS OF ONE BUILD PATCHES FROM SURE~SISIAUNS - REMOVE COMPONENTS OF ADT FILER PATCHES MISC FROM SURE~SISIAUNS - REMOVE MISCELLANEOUS COMPONENTS OF ADT FILER INACT FROM SURE~SISIAUNS - INACTIVATE THE ADT FILER PROCESS FROM SURE~SISIAUNS - PROCESS COMPONENTS AND FILES FOR REMOVAL PXK FROM SURE~SISIAUNS - REMOVE SISIA PROTOCOL ITEM FROM PXK PROTOCOL DELPRO FROM SURE~SISIAUNS - Delete ADT FILER PROTOCOL ENTRIES DEL101 DELETE ONE PROTOCOL FILE ENTRY DELPAR DELETE ADT FILER PARAMETERS AND PARAMETER DEFINITION ENTRIES DELPARM DELETE ONE PARAMETER AND THE CORRESPONDING PARAMETER DEFINITION DEL771 DELETE ADT FILER HL7 APPLICATION PARAMETER ENTRIES DEL870 DELETE ADT FILER HL LOGICAL LINK ENTRIES DEL8994 DELETE ADT FILER REMOTE PROCEDURE FILE ENTRIES DELRTN DELETE ADT FILER ROUTINE FILE ENTRIES AND ROUTINES RD FROM DELRTN~SISIAUNS - WRAPS ~%ZOSF("DEL") DELMG DELETE ADT FILER MAIL GROUP ENTRIES DELTMPLT DELETE ADT FILER TEMPLATES AND FORMS DELFILES SELECTIVELY DELETE ADT FILER FILES THAT DO NOT CONTAIN PATIENT DATA DELFILE FROM DELFILES~SISIAUNS - DELETE ONE FILE DISPARM DISPLAY FILE CONTENTS DEL19 FROM SURE~SISIAUNS - DELETE ADT FILER OPTION FILE ENTRIES 96

97 DELKEY FROM SURE~SISIAUNS - DELETE ADT FILER SECURITY KEY ENTRIES XREF FROM SURE~SISIAUNS - DELETE ADT FILER NEW STYLE CROSS REFERENCES DIK WRAP ~DIK FILEINFO FROM SURE~SISIAUNS - RETURN INFORMATION ABOUT FILE RESLIST FROM SURE~SISIAUNS - DISPLAY INFORMATION ABOUT RESIDUAL COMPONENTS VERYSURE PROMPT FOR OPT-OUT FROM UNINSTALL CLEANUP REMOVE ~TMP("SISIAUNS",$J) AFTER UNINSTALL SISIAUPD ETHNINFO FILE ETHNIC GROUP TO ETHNICITY INFORMATION MULTIPLE IN PATIENT FILE DELETHN DELETE ETHNICITY INFORMATION MULTIPLE PRIOR TO FILING NEW DATA SISIAUT1 IMPORT DEVELOPMENT USE ONLY IMPORT SISIADT AUXILIARY FIELD MAP ENTRIES FROM HOST FILE PROCESS FROM IMPORT~SISIAUT1 - FILE ONE IMPORTED AUXILIARY FIELD MAP SAVEMSG DEVELOPMENT USE ONLY SAVE CURRENT RECEIVED HL7 MESSAGE TO HOST FILE FNAME RETURN A UNIQUE FILE NAME, BASED ON DATE/TIME NOW CONSTANT RETURN VALUE OF CONSTANT FROM FILE ENTRY SISIAUT2 DSPMSG DISPLAY AN HL7 MESSAGE USING DATA FROM FILES 773 AND 772 ADT RETURN CURRENT INPATIENT ADMISSION DATE/TIME FOR ADT-A07 VSIT WRAP ~VSIT API TO CREATE A NEW OUTPATIENT OR INPATIENT VISIT MVP RETURN TRUE IF AND ONLY IF SPECIFIED MOVEMENT HAS A POINTER TO THE VISIT FILE 97

98 SPC RETURN LAST SPECIALTY TRANSFER MOVEMENT IEN FOR THE GIVEN ADMISSION MOVEMENT IEN F2STW NOT SUPPORTED SET VARIOUS INPATIENT CROSS-REFERENCES F2KLW NOT SUPPORTED KILL VARIOUS INPATIENT CROSS-REFERENCES CLRDOD FROM CANCEL DISCHARGE - CLEAR DATE OF DEATH AND RELATED FIELDS CREATE AN IHS PATIENT FILE ENTRY IF ONE DOES NOT EXIST SISIAUT3 INDEX INDEX KEYWORD~VALUE AND RETURN RESULTS IN AN ARRAY BY REFERENCE PREPEVNT PREPARE TO INVOKE EVENT HANDLER TO PROCESS DATA FROM AN INDEXED ARRAY SISIAUT4 EN PUBLIC IMPLEMENTS OPTION SISIADT REPROCESS HL7 MESSAGE REPROC FROM EN~SISIAUT4 - REPROCESS HL7 MESSAGE (FILE 773 IEN) USER WRAP REPROC~SISIAUT4 PRESERVING CURRENT USER DUZ ARRAY PROTOCOL RETURN SUBSCRIBER PROTOCOL IEN - USED IN REPROCESSING A OPTION IMPLEMENTS OPTION SISIADT POINT ACCOUNT NUMBER CKA CHECK/VERIFY ACCOUNT NUMBER AND PATIENT MOVEMENT LINK LINK ACCOUNT NUMBER TO MOVEMENT VTA RETURN TRUE IF AND ONLY IF VISIT TRACKING PARAMETERS HAS AN ADT FILER ENTRY SISIAUTL PSSN RETURN A UNIQUE PSEUDO-SOCIAL SECURITY NUMBER (SSN) VSSN VALIDATE A SOCIAL SECURITY NUMBER (SSN) NAMEFMT WRAP $$NAMEFMT~XLFNAME PNUMFMT FORMAT A PHONE NUMBER 98

99 LINK LINK SISIADT PSEUDO-SSN ENTRY TO VISTA PATIENT ENTRY DGPMDA RETURN MOVEMENT IEN FOR PATIENT x ADMISSION PARSE PARSE RECEIVED HL7 MESSAGE TO COMPONENT LEVEL XFRM TRANSFORM DATA FROM HL7 DATA TYPE TO VISTA (FILEMAN) TYPE NEXTID RETURN NEXT UNIQUE IDENTIFIER FOR STORING PARSED MESSAGE DIV NOT SUPPORTED RETURN SISIADT HL7 INTERFACE PARAMETER FILE DIVISION IEN XCPT RECORD AN EXCEPTION XXCPT SUPPORTED API RECORD AN EXCEPTION USING SUPPORTED API 793 ADAPT ADT FILER EXCEPTIONS TO FILE 79.3 DIERR CREATE GENERIC ADT FILER EXCEPTION TO REPORT FILEMAN ERROR IGNORE RETURN SISIADT EXCEPTION TYPE 'IGNORE' FIELD VALUE FOR GIVEN CODE PURGEX PURGE EXCEPTIONS UP TO 'KEEP' (NUMBER OF DAYS) ASKPURGE PUBLIC USER INTERFACE TO PURGE EXCEPTIONS NOW WRAP NOW~%DTC NOT SUPPORTED DEBUG DEVELOPMENT USE ONLY RECORD DEBUG DATA TO ~XTMP("SISI") SISIAV2 TR TRANSLATE PARSED MESSAGE VALUES ACCORDING TO FILE ENTRIES CONTINUE CONTINUATION OF TR~SISIAV2 - TRANSLATE PARSED MESSAGE PROV LOOKUP PROVIDER USING METHOD DEFINED IN MAIN PARAMETER FILE, FIELDS #11 AND #12 PPRV COMPUTE PRIMARY PHYSICIAN, USING $$PROV~SISIAV2 METHOD APRV COMPUTE ATTENDING PHYSICIAN USING $$PROV~SISIAV2 METHOD 99

100 VLOC COMPUTE VISIT LOCATION USING MAIN PARAMETER FILE FIELD #18.1 METHOD APLOC COMPUTE INPATIENT PRE-ADMIT LOCATION USING MAIN PARAMETER FILE FIELD #18.2 WIEN COMPUTE WARD LOCATION IEN USING MAIN PARAMETER FILE WARD TRANSFORM METHOD X EXECUTE MUMPS CODE IN SPECIFIED FIELD OF FILE ISVISIT RETURN TRUE IF AND ONLY IF VISIT EXISTS FOR DFN x VDT x LOCATION x CLASS EVN6 CONDITIONALLY RETURN VALUE OF EVN.6 EVENT OCCURRED TIME SISIAV20 PXID RETURN A PSEUDO TRANSACTION ID STRING OF SPECIFIED LENGTH CKCFG OPTION IMPLEMENTS OPTION SISIADT CHECK CONFIGURATION SIS CONTINUATION OF CKCFG~SISIAV20 - CHECK ADT FILER ELEMENTS VA CONTINUATION OF CKCFG~SISIAV20 - CHECK VISTA ELEMENTS CKPR CHECK FIELDS #11,#12,and #13 IN MAIN PARAMETER FILE RA CONTINUATION OF CKCFG~SISIAV20 - CHECK RECEIVING APPLICATION W WRITE TEXT SISIAV21 DELVSIT SET DELETE FLAG FOR VISIT AND DELETE POINTER TO VISIT FROM ACCOUNT NUMBER FMVDEL FROM DELVSIT~SISIAV21 - WRAP FILE~DIE TO SET DELETE FLAG FOR VISIT UNDELV WRAP FILE~DIE TO CLEAR DELETE FLAG FOR VISIT VPTDEL DELETE POINTER TO VISIT FROM ACCOUNT NUMBER : TRANSACTION SETCKOUT FILE CHECK OUT DATE&TIME FOR ADMISSION VISIT CORRESPONDING TO INPATIENT DISCH. DELCKOUT DELETE CHECK OUT DATE&TIME FOR VISIT ASSOCIATED WITH SPECIFIED ADMISSION SISIAV22 100

101 ISINP RETURN TRUE IF AND ONLY IF PATIENT IS CURRENTLY ADMITTED AS AN INPATIENT MVTYP RETURN MOVEMENT TYPE IF MOVEMENT EXISTS FOR THE SPECIFIED DFN x DATE/TIME SCHIEN RETURN SCHEDULED ADMISSION IEN IF ONE EXISTS FOR THE SPECIFIED DFN x RESERVATION DUPOV CHECK VARIOUS RULES FOR A DUPLICATE OUTPATIENT VISIT UPDOV FROM VSIT~SISIAUT22 - UPDATE AN OUTPATIENT VISIT MLOG CONDITIONALLY CREATE A SISIADT RECEIVED MESSAGE LOG ENTRY FLOG FROM MLOG~SISIAV22 - FILE VALUE TO RECEIVED MESSAGE LOG FIELD ALOG FILE VALUES TO SISIADT RECEIVED MESSAGE LOG FILE FROM INPUT ARRAY XLOG FILE EXCEPTION TO EXCEPTION MULTIPLE OF RECEIVED MESSAGE LOG FILE ALERT SUPPORTED API CONDITIONALLY GENERATE AN ALERT FOR AN EXCEPTION BULLETIN SUPPORTED API CONDITIONALLY SEND BULLETIN FOR AN EXCEPTION SISIAV23 EN OPTION IMPLEMENTS SISIADT PATCH NOTIFICATION PLIST RETURN LIST OF PATCHES FOR CURRENT ADT FILER VERSION PATCH RETURN TRUE IF AND ONLY IF SPECIFIED PATCH IS INSTALLED STATUS RETURN INSTALL FILE STATUS OF SPECIFIED PATCH XCPT WRAP XCPT~SISIAUTL TO INDICATE THAT A PATCH IS AVAILABLE SISIAV24 RPT NOT SUPPORTED PROCESS AUXILIARY FIELD MAP FOR REPEATING SEGMENTS SISIAV25 ISPCHG RETURN TRUE IF AND ONLY IF CURRENT MESSAGE SPECIFIES A TREATING SPECIALTY CHANGE 101

102 LASTCM RETURN LAST CORRELATED MOVEMENT FOR CURRENT ACCOUNT LASTSPX RETURN LAST SPECIALTY TRANSFER MOVEMENT FOR THIS ACCOUNT SISIAV26 EVAL PUBLIC EVALUATE AN HL7 MESSAGE EXPRESSION Q EXPAND QUOTATION MARKS IN ARGUMENT B EVALUATE CURLY BRACES IN UNQUOTED ARGUMENT A EVALUATE INDIRECTION AND NORMALIZE RETURN VALUE DIM WRAP FILEMAN ~DIM SYNTAX CHECK SISIAV27 GEN OPTION IMPLEMENTS OPTION SISIADT EXPORT CONFIGURATION C COMPILE CONFIGURATION REPORT APPEND APPEND RECORD (VALUE) TO AN ARRAY FLDNAM WRAP FIELD~DID TO RETURN NAME OF A FIELD PARLST RETURN LIST OF ADT FILER PARAMETERS THAT ARE VALUED W WRITE CONFIGURATION REPORT KILL KILL TEMPORARY ARRAY CONTAINING CONFIGURATION DATA SISIAV28 IMPORT OPTION IMPLEMENTS OPTION SISIADT IMPORT CONFIGURATION DISPLAY WRITE CONTENTS OF ARRAY CONTAINING CONFIGURATION DATA FILE PROCESS IMPORTED CONFIGURATION DATA TO ADT FILER AND VISTA FILES APAR FILE SISIADT HL7 INTERFACE PARAMETER FROM IMPORTED DATA XPAR FILE ADT FILER KERNEL PARAMETERS FROM IMPORTED DATA 102

103 AMAP FILE SISIADT AUXILIARY FIELD MAP ENTRIES FROM IMPORTED DATA CONS FILE SISIADT CONSTANTS ENTRIES FROM IMPORTED DATA IAPI FILE SISIADT IMPLEMENTATION-SPECIFIC API ENTRIES FROM IMPORTED DATA SAN FILE HL7 APPLICATION (ADT FILER PROTOCOL : SENDING APPLICATION) EVNPROT FILE ADT FILER EVENT PROTOCOLS FROM IMPORTED DATA XACTPROT FILE ADT FILER EXTENDED ACTION PROTOCOLS FROM IMPORTED DATA USER FILE ADT FILER PIMS HL7 USER FROM IMPORTED DATA SFN FILD SENDING FACILITY ID IN INSTITUTION FILE IDENTIFIER MULTIPLE UNK DO NOTHING TAG PARSE / EXTRACT TAG FROM CONFIGURATION FILE SECTION ID RECORD EXIT CLEANUP VARIABLES AND EXIT CONFIGURATION IMPORT OPTION FTG WRAP $$FTG~%ZISH TO IMPORT CONFIGURATION FILE TO TEMPORARY GLOBAL STORE INDEX CONSTRUCT ONE OR TWO LEVEL INDEX FOR PARSING OF CONFIGURARION FILE FLDNUM WRAP $$FLDNUM~DILFD TO RETURN FIELD NUMBER FOR DD# AND FIELD NAME ENTITY RETURN ENTITY VARIABLE POINTER FORMAT FOR SPECIFIED ENTITY FILE AND IEN KILL CLEANUP TEMPORARY STORAGE AFTER PROCESSING AN IMPORTED CONFIGURATION FILE SISIAX X EXECUTE AN IMPLEMENTATION-SPECIFIC OR SUPPORTED API IN CONTEXT SUPADT SUPPORTED API IMPLEMENTS VALIDATE INPT ADMIT D/T UPDATE SUPPORTED API SISIAXW INIT NOT SUPPORTED ESTABLISH MINIMAL ADT FILER CONTEXT DFN PUBLIC 103

104 COMPUTE DFN FROM AN ARGUED PID SEGEMENT (NOT CURRENT MESSAGE) SISIUTL COPYMSG COPY HL7 MESSAGE TO AN ARRAY (BY REFERENCE) CPYMSG COPY HL7 MESSAGE TO AN ARRAY (USES MERGE COMMAND) XSEG DEVELOPMENT USE ONLY EXTRACT SELF-CONTAINED SEGMENT FROM MESSAGE VALUE DEVELOPMENT USE ONLY RETURN FIELD OR COMPONENT VALUE SPECIFIED BY ARGUMENT LIST ACTIVE RETURN TRUE IF AN ONLY IF THE ADT FILER HL7 APPLICATION IS ACTIVE UESC CONVERT HL7 ESCAPTED DELIMITERS IN ARGUMENT STRING UC TRANSLATE ARGUMENT STRING TO UPPERCASE NOW WRAP NOW~%DTC NOT SUPPORTED VALNAME NOT SUPPORTED VALIDATE A NAME - RETURN TRUE IF NAME MATCHES UP TO SOUNDEX SOUNDEX CLONED FROM FILEMAN ROUTINE ~DICF5 (SOUNDEX) TRIM TRIM LEADING AND TRAILING SPACES FROM ARGUMENT STRING DEBUG RECORD DEBUG INFORMATION IN ~TMP("SISI") 104

105 ADT Filer Graphical User Interface (Deprecated) The ADT Filer Graphical User Interface (version 1.8) is no longer supported in version 2.0. The following description is retained for backward compatibility. A browser-based interface is planned for future development to replace the client-server GUI that was provided in version 1.8. However, it is not certain whether or when this replacement interface will become available. Version 1.8: A VistA RPC-Broker based graphical user interface may be used to assist in day-to-day monitoring and interface management. The program is distributed as a standalone executable adtfiler.exe or as an install setup. The following description refers to the adtfiler GUI executable. Copy the program to a convenient location, for example, C:\Program Files\VistA\ADT Filer\ Next create a shortcut to the executable. Modify the shortcut s Target command line to include s=brokerserver p=listeningport parameters as illustrated below. Optionally, access and verify codes may be supplied with the c= parameter for automatic logon to VistA. The ADT Filer GUI application is intended for use by programmers. However, if it is desired to grant access to a user who does not have VistA programmer privileges it will be necessary to assign the SISIADT RPC broker-type option to that user. On startup the ADT Filer GUI should first display the VistA logon form, unless access and verify codes have been supplied in the open parameters. The program consists of tabbed-pages, each page relating to a different aspect of the ADT Filer application. 14 After successful logon the program opens to the Configuration page displaying values for most configuration fields (provided the configuration has been defined). 14 Different revisions of the program included different features, tabs, form layouts, etc. 105

106 The illustration above has sample field values. In the upper left panel some ADT event types are disabled (grayed-out). Two of these ADT-A06 and ADT-A07 are linked to other events, ADT-A01 and ADT-A03 respectively. 15 ADT-A05 processing is always enabled. ADT-A28 and ADT-A31 event types should be enabled or disabled at the protocol level. Other panels in the top half of the configuration page are self-explanatory. These values are editable from the GUI. The lower information display (yellow) isn t editable in version 1.6, but may be editable in a future replacement product. Finally, the status display shows generic HL7 status--not ADT Filer-specific. Link status is not included as the VistA multi-threaded listener may serve many independent HL7 interfaces, not just the ADT Filer. The ADT Filer Field Maps page has an event driver protocol selection box at the upper right. Once a protocol has been selected the associated auxiliary field map entries for the protocol are displayed. However, only those map entries for which the protocol is primary 16 are displayed. Field map entries for Friend protocols can only be exhibited by identifying the map entry s primary protocol. 15 VistA does not distinguish between inpatient admission and a status change from outpatient to inpatient. 16 i.e. the protocol contributes to the primary key 106

107 When a protocol has been selected, associated map entries should be displayed as illustrated below. When a grid cell is entered its contents are copied to the edit box on the top left. For example, entering the Transform cell on the second row copies the NK1.3 transform to the edit box. This action also switches to the Map Details tabbed page. It is planned to edit cell entries and save changes from this page in a subsequent revision. 107

108 The Constants tabbed page also has a selection combo box, located at the top of the left panel. Selecting a table name from this list causes the table contents to be displayed in the main grid on the right. Note that buttons relating to creating new entries and editing existing entries (bottom of left panel) are temporarily disabled. Once these functions are enabled the buttons will display as active. The next tab displays Exception Log contents in inverse chronological order from the top. 108

109 Up to the 100 most recent exceptions are displayed. Some exceptions include the HL7 Message control ID and some include other qualifying data. Entering a table cell containing a message number (via mouse click or etc.) automatically switches the display to the Messages page. If the message is still accessible from the VistA HL7 MESSAGE ADMINISTRATION file and HL7 MESSAGE TEXT file, it will be formatted and displayed on this page. 17 Entering a field within the displayed message will cause the Segment.Sequence.Component to be displayed in the status bar. At this point the display does not automatically switch to the Details page. However, if a field is documented in the VistA HL7 FIELD file (#771.1), additional information will be shown in the Details view for the field. It is important to note that the HL7 FIELD file as distributed is incomplete and bears erroneous descriptions for some fields. 18 Patient Account Number: The ADT Filer includes a file to track patient accounts. Since many external systems use patient account number to connect related patient events, the Filer also tracks this external account number and links it to patient movements, outpatient visits, and related data. 17 Processed HL7 messages are usually purged within a few days of being received, in order to conserve storage. 18 Not all fields are described for each documented segment. Some fields (e.g. in the PV1 segment) are described erroneously. 109

110 Each transaction within an account should correspond to an HL7 message describing an ADT event, such as admission, transfer, update or discharge. The Filer s GUI Account Details tab displays account transaction history in chronological order, either by account number (i.e. one account) or by patient (possibly multiple accounts). When activity is recent it is possible also to view the associated HL7 message by selecting the Transaction Control ID cell for the entry. This function depends upon the message s availability. As previously noted, once processed, VistA HL7 messages are retained for a limited period of time and then purged. For events that create patient movements, the TRANSACTION CONTROL ID multiple of the ACCOUNT NUMBER file includes a pointer to the movement. Specialty transfer movements that are associated with inpatient admissions are recorded in the CORRELATED MOVEMENT sub-field. A future revision of the ADT Filer may support the creation of specialty transfer movements that take place after the original admission and its correlated transfer have been filed. The CORRELATED MOVEMENT sub-field will record pointers to these movements also, if and when this feature is introduced. Whenever a patient movement is cancelled (e.g., events ADT-A11, ADT-A12, ADT-A13, etc.) the corresponding VistA movement is deleted. At the same time, the ADT Filer deletes the MOVEMENT pointer in the ACCOUNT NUMBER file s TRANSACTION CONTROL ID multiple entry for the event that created the movement. 110

111 Partial ADT Filer Exceptions List 19 Exceptions Context and Log Mode Exception Context Log Mode A01: OPT Appt DT A01 Verbose A01: OPT Invalid Loc A01,A07 Normal A01: OPT Visit DT A01 Normal A01: OPT VSIT failed A01,A07 Normal A02: not implemented A02 Verbose A02: DGPMVI undef A02 Normal A02: Lock failed A02 Normal A02: New PM failed A02 Normal A02: No 'P' node A02 Normal A02: No transfer DT A02 Normal A02: OPT Invalid Loc A02 Normal A02: OPT VSIT failed A02 Normal A03: No matching ADM A03 Normal A03: OPT DDT missing A03 Normal A05: K Invalid ADT A05 Normal A05: K Invalid VLOC A05 Normal A05: K REG failed A05 Normal A05: K VSIT failed A05 Normal A05: Opt not impl. A05 Verbose A06: Invalid PV1.2 A06 Normal A07: Invalid PV1.2 A07 Normal A08: (Inp) No adm A08 Verbose A08: (Opt) No adm A08 Verbose A08: Bad DFN A08 Normal A08: New MRN exists A08 Normal A08: No account A08 Normal A08: No account DFN A08 Verbose A08: No DFN A08 Verbose A08: not implemented A08 Verbose A10: OPT Invalid Loc A10 Normal A10~SISIADTM No IENS A10 Normal A11 Bad mvmt context A11 Normal A11 requires autoptf A11 Normal A11: Pt. class check A11 Verbose A11: VISIT not found A11 Normal A11~SISIADTC reached A11 Very Verbose A12: cancel ASIH xfr A12 Normal A12: No prior mvmnt A12 Normal A12: not implemented A12 Verbose A12: xfr not found A12 Normal A12~SISIADTC reached A12 Very Verbose A13: Inpt. as A06 A13 Very verbose A13: VISIT not found A13 Normal A13~SISIADTC reached A13 Very Verbose A36: ~XMD Error A36 Normal A17: Bad DFN or DFN2 A17 Normal A28: Patient Exists A28 Verbose A28~SISIADTM No IENS A28 Normal A31~SISIADTM No IENS A31 Normal 19 This listing was not updated in the 2014 revision of this document. 111

112 A36: ~XMD Error A36 Normal A47 DFN not found A47 Normal A47 Invalid context A47 Normal A47 New PPID exists A47 Normal A47 PPID field map A47 Normal A47 PPID map IENS A47 Normal A47 PPID replaced A47 Very verbose A47 Repl PPID failed A47 Normal Axx: Invalid Class Multiple events Normal Axx: No admission DT A01,A02,A03 Normal Axx: Unknown class K-A01,A04,A05 Normal Axx: XDOK chk failed A02,A03,A07.. Normal Axx-K not impl. A10,A36 Normal Axx~SISIADT0 reached Any event Very verbose Axx~SISIADTK reached K-various Verbose Adm: Mvt DT conflict A01,A06 Verbose ADMIEN~SISIACCT fail A08 Verbose ADT-A01 Disabled A01 Very verbose ADT-A02 Disabled A02 Very verbose ADT-A03 Disabled A03 Very verbose ADT-A04 Disabled A04 Very verbose ADT-A05 Disabled A05 Very verbose ADT-A06 Disabled A06 Very verbose ADT-A07 Disabled A07 Very verbose ADT-A08 Disabled A08 Very verbose ADT-A11 Disabled A11 Very verbose ADT-A12 Disabled A12 Very verbose ADT-A13 Disabled A13 Very verbose ADT~SISIACCT failed A08 Verbose ALL~SISIAGU Param Er Map processing Normal APHY External Spec.Transfer Very verbose APHY VistA Spec.Transfer Very verbose APRV: No external ID provider ID Very verbose Application inactive ALL Very verbose ASIH +30 dsc failed A01 Verbose ASIH No current adm A01 Normal Call ARM DFN=<IEN> Spec.Transfer Very verbose Cannot admit lodger A01,A02 Normal Cannot compute DFN A03 Normal Chain Events No DFN Post processing Normal Cncl pre-admt no DFN A38 Normal Cncl pre-admt No sch A38 Normal Computed APRV <NAME> Resolve provider Verbose Computed PPRV <NAME> Resolve provider Verbose Computed provider ID Resolve provider Very verbose <DATA2PCE ERROR> S12,DATA2PCE Normal D2P: Invalid param S12,DATA2PCE Normal D2P: ~PXAPI Error S12,DATA2PCE Normal D2P: <Error code> S12,DATA2PCE Normal Dequeue A01~SISIADT A01 Very verbose Dequeue A05~SISIADT A05 Very verbose Dequeue A06~SISIADT A06 Very verbose Dequeue A07~SISIADT A07 Very verbose DGPMVI undefined A01,A03 Normal Dis: Mvt DT conflict A03,A07 Verbose Disallow future VSIT A01,A05,... Very verbose Disallow MRN update A08 Very verbose 112

113 Dsch: never admitted A03 Normal Dup Inpt Admission A01,A13 Normal Dup Inpt Discharge A03,A07 Normal Dup. movement DT A01,A06,A03,A07 Verbose Editing opt location A08 Very verbose EN~SISIADT(msg,evn) ALL Very verbose EN~SISIADTI reached Map processing Verbose EN~SISIADTI No msg Map processing Normal EN~SISIAGU Param Er Map processing Normal EN~SISIASIU(msg,evn) ALL SIU Very verbose Error in ~DGPMVDL A11,A12,A13 Normal EVN: ACKONLY~SISIADT Any event Verbose <EVN>: DIERR context Any event Very verbose <EVN> failure code nn A17,... Verbose External provider ID Resolve provider Very verbose File 43 undefined A01,A02,A03 Normal FromASIH No +30 PMDA A03 Normal FromASIH No +30 DsDT A03 Normal FromASIH No LTC ADT A03 Normal FromASIH No LTC PMDA A03 Normal General error A01 Normal GT1 SPONS PERS fail Post-events Verbose GT1 SPONSOR fail Post-events Verbose GT1 to API failed Post-events Verbose GT1 to IB failed Post-events Verbose GT1 to RPMS failed Post-events Verbose GT1 to RPMS not impl Post-events Verbose GUAR update failed A28-A31 Verbose Import: No file name Map Import Normal Import: Open failed Map Import Normal In A36~SISIADTX A36 Very verbose In ADT~SISIADT8 A08 Very verbose In ADTI~SISIADT81 A08 Very verbose In ADTO~SISIADT8 A08 Very verbose In Appointment Evnts Post-events Verbose In APRV~SISIAV2 Resolve provider Very verbose In AVS~SISIADT8 A08 Very verbose In DSC~SISIADT8 A08 Very verbose In EDIT~SISIADTI Spec.Transfer Very verbose In FRASIH~SISIADTZ A03 Very verbose In FTS~SISIADT8 A08 Very verbose In LOCO~SISIA081 A08 Very verbose In MA13~SISIADTZ A13 Very verbose In ONE~ Compute IENS Map processing Very verbose In ONE~ Define FDA Map processing Very verbose In ONE~ Extract data Map processing Very verbose In PHY~SISIADT8 A08 Very verbose In PPRV~SISIAV2 Resolve provider Very verbose In PROCESS~SISIAGU Map processing Verbose In RMBD~SISIADT8 A08 Very verbose In SPEC~SISIADTS Spec. Transfer Verbose In TOASIH~SISIADTZ A01 Very verbose In UPDFTS~SISIADT8 A08 Very verbose In WARD~SISIADT8 A08 Very verbose Info: Chained Events Post Processing Very verbose Info: OPT admission A01 Verbose Info: OPT discharge A03 Verbose 113

114 Info: Test exception Protocol Verbose Insufficient data Post-events Verbose INSURER not found A28-A31,P01-P05 Normal INSURER unk type A28-A31 Normal Invalid movement IEN A01,A03 Normal Lock request failed A01,A03 Normal MasterSwitch OFF Any event Verbose MasterSwitch ON Any event Verbose MasterSwitch SUSPEND Any event Verbose MCARE Update failed A28-A31 Normal MCAID Update failed A28-A31 Normal Missing 42->44 ptr A01,A06 Verbose Missing patient SSN A01,A02,A03 Normal Missing patient XID Registration Verbose Missing PID segment A01,A02,A03,A04 Normal A05,A38 Missing PTF record A01 Normal <MSG>-<EVN> event queued Any event Very verbose NEW~SISIADTS reached Spec.Transfer Very verbose No admission date A01,A03 Normal No discharge date A03 Normal No dup VISIT created A01,A06,A03,A07 Verbose No movement IEN A11,A12,A13 Normal OADT~SISIACCT failed A08(as A01) Verbose ONE~SISIAGU Bad File Map processing Normal ONE~SISIAGU Bad Fld Map processing Normal ONE~SISIAGU Bad IENS Map processing Normal ONE~SISIAGU reached Map processing Verbose Opt: A05 not implm. A05 Very verbose Opt: Visit not found A03,A06 Verbose Opt: Invalid DDT A03,A06 Normal OPT VISIT disallowed A01,A05,A06... Verbose ORD~SISIAGU Bad PROT Map processing Normal ORD~SISIAGU Param Er Map processing Normal ORD~SISIAGU reached Map processing Verbose P01: Missing MRN P01 Normal Patch URL not found Auto patch check Verbose Patient died A01,A02 Normal Patient not found P05 Normal Please install patch Auto patch check Verbose PPHY External Spec.Transfer Very verbose PPHY VistA Spec.Transfer Very verbose PPRV: No external ID Resolve provider Verbose PROCESS: Bad IENS Map Import Normal PROCESS: Bad TYPE Map Import Normal PROCESS: No protocol Map Import Normal PRVNS Update failed A28-A31 Normal Pt Loc not updated A06,A07 Very verbose Registration aborted A01,A04,... Normal Registration failed A01,A02,A03 Normal Reg: Can't file PPID Registration Normal Reg: Duplicate MRN Registration Normal Reg: Duplicate SSN Registration Verbose Reg: Invalid PPID Registration Normal Reg: PPID lock fail Registration Normal Reg: Recurring Pt. Registration Verbose RMBD: Invalid config A08 Verbose 114

115 RPC: <message> A03,A06 Verbose Rtn~XTHC10 not found Auto patch check Verbose S12: Bad AIL Loc S12 Normal S12: Bad Appt DT S12 Normal S12: Bad Hosp Loc S12 Normal S12: Bad PT ID S12 Normal SAVEMSG: No message Save message Normal SAVEMSG: Open failed Save message Normal Sched Admit Bad ADT A05 Normal Sched Admit failed A05 Normal Sched No primary A05 Verbose Sched No ward A05 Verbose SPEC: No admission Spec.Transfer Normal SPEC: No ASK Spec.Transfer Verbose SPEC: No attending Spec.Transfer Verbose SPEC: No primary Spec.Transfer Verbose Undefined event type ALL Normal UPDATE: No DFN P01,P05 Normal Update DDT mvmt type A08 Verbose Update DDT no DSCHRG A08 Verbose Update DDT no MVMT A08 Verbose UPDATE~ Reg. Failure A01,A04,... Normal Upd dup VST for acct A07 Verbose V31 PTF not enabled Spec.Transfer Very verbose ~VSIT Error <IEN> A01,A06,A03,A07 Normal WARD precheck failed A01,A06 Normal XFER: Never admitted A02 Normal XFER: Not inpatient A02 Verbose XT*7.3*123 not found Auto patch check Verbose File 79.3 HL7 MESSAGE EXCEPTIONS: When the ADT Filer s LOG STATUS parameter is set to 1 (NORMAL), exceptions are recorded by default to both the ADT Filer s SISIADT EXCEPTION file and to File 79.3 HL7 Message EXCEPTIONS. To avoid duplicate recording of exceptions to File 79.3, the RECORD EXCEPTION implementation-specific API can set the variable SIS793=0. Note that verbose exceptions are not recorded to File 79.3 regardless of whether this variable is set or not. It is also possible to override the ADT Filer s exception recording entirely by setting the variable SISXQUIT=1 in the RECORD EXCEPTION implementationspecific API. This variable is effective regardless of the LOG STATUS setting, and prevents recording the exception to either the ADT Filer s SISIADT EXCEPTION file or the HL7 MESSAGE EXCEPTIONS file. Issuing Alerts for Exceptions: It is possible to configure the ADT Filer to issue an Alert for one or more identified exceptions. This capability should be used sparingly, for obvious reasons. To specify one or more users to receive an alert for a given exception, add the user or users to the ALERT USER multiple in the SISIADT EXCEPTION TYPE file (# ). Then, add or edit an existing entry in the SISIADT IMPLEMENTATION- SPECIFIC API file for the RECORD EXCEPTION supported API. The following 115

116 example illustrates how to trigger alerts for exceptions that have specified alert users, and at the same time to suppress recording exceptions to the HL7 MESSAGE EXCEPTIONS file (#79.3). NAME: RECORD EXCEPTION XECUTE: D ALERT^SISIAV22(SISXDT,SISXCODE,SISXID,SISXDATA) S SIS793=0 Q NOTES: Record alert for selected exceptions and... Suppress recording exceptions to File 79.3 in 'normal' mode. The ADT Filer API invoked in the above example ALERT^SISIAV22 wraps the kernel SETUP^XQALERT API. The alert will not necessarily include all available information about the exception, but in general will have the following form: ADT Filer exception 'Adm: Mvt DT conflict' in <message ID> where <message ID> refers to the HL7 message control ID of the event that caused the exception. Information in the DATA field (1-100 characters) of the exception, if present, will also be displayed in the Alert. Intentionally Ignoring Exceptions: The field named IGNORE in the SISIADT EXCEPTION TYPE file suppresses recording exceptions of the given type. Setting IGNORE to YES will cause the ADT Filer to skip recording the exception (or passing the exception to an implementation-specific exception handler) when it would otherwise be recorded or processed. The purpose of this flag field is to suppress recording of nuisance exceptions. If an implementation is configured such that a particular exception type is always recorded, and provides no useful information, this field can be used to skip recording exceptions of the particular type. This field value does not influence the circumstance(s) that caused the exception. In other words, if the exception is FATAL (aborts processing), the effect remains the same and processing will abort. However, if the exception type is flagged as IGNORE, the exception will not be saved in the SISIADT EXCEPTION file. Mail Group: The SISIADT EXCEPTION TYPE file also includes a MAIL GROUP field, which, if valued, identifies a mail group to receive a bulletin about the exception. As with the ALERT USER, this field should be used sparingly, and only for exceptions that merit special attention. To use the MAIL GROUP feature, the implementing site should define one or more MAIL GROUP entries to receive information about ADT Filer exceptions. However, simply adding a mail group to the exception type alone does not suffice to generate a bulletin for the exception. Implementing code must also be supplied. As with alerts, the implementing code may reside in the RECORD EXCEPTION entry of the SISIADT IMPLEMENTATION-SPECIFIC API file. The following is an example RECORD EXCEPTION entry: 116

117 NAME: RECORD EXCEPTION XECUTE: D ALERT^SISIAV22(SISXDT,SISXCODE,SISXID,SISXDATA),BULLETIN^SISIAV22 (SISXDT,SISXCODE,SISXID,SISXDATA,.SISXWP) S SIS793=0 Q NOTES: Record alert for selected exceptions and... Suppress recording exceptions to File 79.3 in 'normal' mode. Record bulletin for exception. Note that the above is an example only. The actual entry should reflect specific requirements of the implementation. Suppose that the exception 'Info: Test exception' points to the mail group SIS ADT FILER EXCEPTION, and that INTERFACE,ADMIN is a MEMBER of this group. Suppose further, that the PIMS HL7 USER field of File identifies a user named FILER,ADT. Under the above conditions, when the Info: Test exception is recorded, the following VistA Mailman message will be sent to the user INTERFACE,ADMIN: Subj: ADT Filer Exception [#227] 12/06/10@12:40 3 lines From: FILER,ADT In 'IN' basket. Page ADT Filer exception 'Info: Test exception' Exception recorded on Dec 06, 2010@12:40:49 Depending on Mailman configuration settings, it is also possible to auto-forward the exception message to a remote address. However, caution should be used to ensure that no protected health information (PHI) is included in the forwarded message. If an exception contains additional data or word-processing data, the Mailman message will also include these elements. 117

118 Common Fatal Exceptions Most exceptions recorded in Normal log mode are fatal, in the sense that they interrupt event processing at the point where they occur. Rarely, a verbose exception may also be fatal. Post-processing of auxiliary map entries may or may not be affected by interruption in event processing caused by an exception. This section provides additional information about the most common Normal mode exceptions. A01: OPT Invalid Loc The outpatient visit location could not be determined using the COMPUTE VISIT LOCATION code, or by the ADT Filer s default method in which the value in field PV1.3.1 (assigned patient location, point of care) is used to lookup the HOSPITAL LOCATION file entry by way of the ABBREVIATION field cross-reference. A02: No matching ADM While processing an inpatient transfer no admission movement could be found for the date/time computed. Admission date/time is first computed from the patient account record. If not found there, the value in PV1.44 of the current message is used. A11: VISIT not found An outpatient visit was cancelled and the original visit could not be found. The search proceeds from the current transaction backward through previous transactions for the same account. Only outpatient transactions are considered. The exception occurs when all transactions have been traversed and none correspond to an outpatient visit. A13: VISIT not found An outpatient discharge was cancelled and the original visit could not be found. Search conditions are analogous to visit cancellation, described in the previous paragraph. Cannot compute DFN This exception applies to both inpatient and outpatient discharges. DFN (patient internal entry number) is computed according to the method specified in the SISIADT HL7 INTERFACE PARAMETER file, COMPUTE DFN field. If this fails, a social security number lookup is performed on the VistA PATIENT file. The exception results if both attempts to compute DFN fail. Dsch: never admitted This exception occurs when a patient is discharged from inpatient status (or changed from inpatient to outpatient) and no admission movement cannot be found. It is similar to the A02: No matching ADM exception except stronger, in the sense that this test precedes the admission date/time match. Inp ADM VISIT failed Inpatient admissions should result in both a VistA patient movement and a visit. The API that creates a VISIT file entry has several required fields including HOSPITAL LOCATION. This exception usually occurs when the ROOM-BED => WARD LOCATION => HOSPITAL LOCATION cannot be computed for an inpatient admission. An incomplete PATIENT MOVEMENT entry will have been created in this case. 118

119 XFER: Never admitted This exception is analogous to the Dsch: never admitted exception. Before attempting to match the current inpatient transfer to an admission it is determined that no admission movements are on record for the patient. 119

120 SISIADT EXCEPTION TYPE File Contents (September 2012) Meaning of Exception Codes The following descriptions are produced by captioned output from the SISIADT EXCEPTION TYPE file. For updated information, use Fileman to examine this file. CODE: <DATA2PCE ERROR> SHORT DESCRIPTION: Text of error returned by $$DATA2PCE~PXAPI This exception arises in the context of processing a 'new appointment' event as an outpatient encounter / visit (not appointment). The event processor calls $$DATA2PCE~PXAPI to create a visit. The exception records the first 20 characters of the error returned by this call (if it fails). ROUTINE: SISIAS12 CODE: <EVN> DGPMDA=<IEN> SHORT DESCRIPTION: Reports patient movement IEN in post-event processing context. ROUTINE: SISIADBA CODE: <EVN> DGPMT=<IEN> SHORT DESCRIPTION: Reports patient movement transaction type in post-event processing context. ROUTINE: SISIADBA CODE: <EVN> failure code nn SHORT DESCRIPTION: A failure occurred for the named event. Code indicates cause of failure. This is a generic exception. It may be fatal or informational. The event ID and code number may provide additional information in the context of the exception. For example, A17 failure code 1 A17 failure code 2 A17 failure code 3 A17 failure code 4 Patient locations do not reference same ward Message ward location differs from VistA Message room-bed differs from VistA room-bed?? Possibly invalid movement transaction type Supported and implementation-specific APIs may use this exception type to record miscellaneous information pertaining to the event and function being performed. ROUTINE: SISIAEX CODE: <EVN>: Bad AIL Loc SHORT DESCRIPTION: Appointment location in AIL segment could not be resolved. When processing a 'new appointment' event, the ADT Filer was unable to resolve the location specified in the AIL segment (AIL.3). ROUTINE: SISIAT12 CODE: <EVN>: Bad Appt DT SHORT DESCRIPTION: The ADT Filer could not compute the appointment date/time. The 'new appointment' event processor attempted to obtain appointment date/time from AIS.4, and failing that from SCH Both attempts failed. ROUTINE: SISIAT12 120

121 CODE: <EVN>: Bad Hosp Loc SHORT DESCRIPTION: Appointment location could not be resolved (multiple events). HL7 message segments failed to provide a resolvable location for the appointment and no default location was specified in the SISI DEFAULT VISIT LOCATION parameter. ROUTINE: SISIAT12 CODE: <EVN>: Bad PT ID SHORT DESCRIPTION: Appointment could not be processed for unknown patient. Patient ID could not be resolved from account specified in the PID segment. The parameter SISI SIU-S12 REGISTER PATIENT does not support registering a new patient in the context of processing appointments. ROUTINE: SISIAT12 CODE: <EVN>: DGPMVI undef SHORT DESCRIPTION: A variable required for processing an inpatient transfer was undefined. This exception should not occur, as it relates to internal processing in VistA bed-control routines. The context is an inpatient transfer event. Notify the developer if this exception is recorded. ROUTINE: SISIADT2 CODE: <EVN>: DIERR context SHORT DESCRIPTION: An error was reported by Fileman. Details are recorded as exception DATA. While processing the specified event specified in the <EVN> part of the exception, Fileman (e.g., FILE^DIE or UPDATE^DIE or etc.) reported an error. The text of the Fileman error is recorded in the DATA part of the exception. The CODE part of the exception records the event type, the constant DIERR, indicating a Fileman error occurred, and additional contextual information. Examine the exception's DATA field for the text of the error reported by Fileman. This exception can occur in many different contexts, i.e., from different ADT Filer routines. Additional contexts may be added to this exception, as needed (for debugging, etc). CODE: <EVN>: DIERR context SHORT DESCRIPTION: An error was reported by Fileman. Details are recorded as exception DATA. While processing the specified event specified in the <EVN> part of the exception, Fileman (e.g., FILE^DIE or UPDATE^DIE or etc.) reported an error. The text of the Fileman error is recorded in the DATA part of the exception. The CODE part of the exception records the event type, the constant DIERR, indicating a Fileman error occurred, and additional contextual information. Examine the exception's DATA field for the text of the error reported by Fileman. This exception can occur in many different contexts, i.e., from different ADT Filer routines. Additional contexts may be added to this exception, as needed (for debugging, etc). 121

122 CODE: <EVN>: Lock failed SHORT DESCRIPTION: Another process is editing the same patient movement. While attempting to process an inpatient transfer, the ADT Filer found that another process had locked the same patient's movements. Thus, either the current movement or a related movement was being edited by another process, possibly a concurrent ADT Filer process. This exception is most likely to be recorded when the interface is restarted after down time, and multiple messages are in queue for processing. ROUTINE: SISIADT2 CODE: <EVN>: New PM failed SHORT DESCRIPTION: Attempt to create a transfer movement failed. This exception relates to internal processing in a VistA bed-control routine, and should not occur under normal circumstances. Notify the developer if this exception is recorded. ROUTINE: SISIADT2 CODE: <EVN>: No admission DT SHORT DESCRIPTION: Admission date/time could not be computed (multiple events). When processing a transfer or discharge, or when processing an admission, the admission date/time could not be computed from the account's transaction history. This exception could result from failure to process a previous message, or from manual editing of the transaction history. ROUTINE: SISIADT1 ROUTINE: SISIADT2 ROUTINE: SISIADT3 CODE: <EVN>: No matching ADM SHORT DESCRIPTION: Could not compute the corresponding admission for a transfer. When processing an inpatient transfer the corresponding admission movement IEN could not be computed. The exact cause depends on the type of transfer (i.e. ordinary inter-ward transfer or to/from ASIH), and the previous transaction history of the account. ROUTINE: SISIADT2 CODE: <EVN>: No transfer DT SHORT DESCRIPTION: Transfer date/time could not be computed from EVN.3 or EVN.2. For transfer events, PV1.44 is presumed to have the original admission date/time, and EVN.3 the (planned) transfer date/time. If EVN3 is not valued, the ADT Filer uses EVN.2. An exception is recorded when both fail. ROUTINE: SISIADT2 CODE: <EVN>: XDOK chk failed SHORT DESCRIPTION: One of several 'sanity checks' on the discharge failed. When processing an inpatient discharge, the ADT Filer checks several conditions, including the patient's most recent movements for the account, and the patient's status (i.e. inpatient or lodger). Basically, the checks are for inconsistencies in the movement or transaction histories that relate to the proposed discharge. The exception is recorded if any check fails. ROUTINE: SISIADT2 ROUTINE: SISIADT3 122

123 CODE: <MSG>-<EVN> event queued SHORT DESCRIPTION: Displays the task number after scheduling an event processing task This exception is recorded immediately after scheduling an event processing task, i.e., in the HL7 processing routine thread. The purpose is to display the task number that was assigned for the event processing background task. Each scheduled messageevent should spawn a background event processing task (under normal ADT Filer usage, when background processing of event tasks is enabled). The task number of the de-queued task may be correlated with the one recorded in the present exception. ROUTINE: SISIADT ROUTINE: SISIABAR ROUTINE: SISIAPPT ROUTINE: SISIASIU CODE: A01: Invalid class SHORT DESCRIPTION: Implementation-specific patient class requirement failed. This is an implementation-specific exception that is recorded for non-inpatient admissions when admission is not supported for the specified patient class. ROUTINE: SISIADTK CODE: A01: OPT Appt DT SHORT DESCRIPTION: Expected admit date (PV2.8) was missing or invalid. When processing an outpatient admission as an appointment, the ADT Filer checks PV2.8 for an 'expected admit date.' If this fails, an exception is recorded. However, processing continues. ROUTINE: SISIADTO CODE: A01: OPT Invalid Loc SHORT DESCRIPTION: Location could not be computed for an outpatient admission. Outpatient admission (VISIT) location is computed, first according to the rule specified in the COMPUTE VISIT LOCATION field of the ADT Filer's main parameter file SISIADT HL7 INTERFACE PARAMETER (version 2), and if this fails, by looking up the value in PV1.3.1 in the "C" crossreference of the HOSPITAL LOCATION file, and if this fails, by using a value specified in the SISI DEFAULT VISIT LOCATION parameter. The exception is recorded when all attempts to resolve the visit's location fail. ROUTINE: SISIADTO CODE: A01: OPT Visit DT SHORT DESCRIPTION: Could not compute outpatient visit date/time. This exception can occur in A01, A04, or A07 event processing, and means that the outpatient visit date/time could not be resolved in the particular event context being processed (either PV1.44 or EVN.2). ROUTINE: SISIADTO CODE: A01: OPT VSIT failed 123

124 SHORT DESCRIPTION: The ~VSIT api wrapper returned an error for an outpatient visit. When the ADT Filer resolves required elements for creating an outpatient visit it invokes the ^VSIT api (from certain events, such as ADT-A01). The ADT Filer's wrapper for this API may record an exception, such as 'No dup VISIT created' or an error returned by the VistA API itself. Or, the wrapper may not record an error. However, if the API fails to return a visit IEN, the current exception will be recorded (in the outpatient context). ROUTINE: SISIADTO CODE: A01~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A01 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A01 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A02: Invalid class SHORT DESCRIPTION: Implementation-specific patient class requirement failed. This is an implementation-specific exception that is recorded for non-inpatient transfers, when transfer is not supported for the specified patient class (generally any class that would not process as a VistA inpatient). ROUTINE: SISIADTK CODE: A02: No 'P' node SHORT DESCRIPTION: Inpatient transfer post-events failed. No 'prior' movement data found. Before unwinding movement post events for an ADT-A02, a check showed that the 'prior' data node in ^UTILITY was missing. This generally means that the transfer itself must have failed, and another (preceding) exception should indicate the point of failure--but not necessarily. Probably the A02 context is invalid, patient not currently admitted to inpatient status, or etc. ROUTINE: SISIADBA CODE: A02: No transfer DT SHORT DESCRIPTION: No (outpatient) transfer date/time found in EVN.3 or EVN.2. The ADT Filer could not process an outpatient transfer as a new visit because the planned date/time of event and event date/time were not resolvable. ROUTINE: SISIADTO CODE: A02: OPT Invalid Loc SHORT DESCRIPTION: Location could not be computed for an outpatient transfer Outpatient transfer (VISIT) location is computed, first according to the rule specified in the COMPUTE VISIT LOCATION field of the ADT Filer's main parameter file SISIADT HL7 INTERFACE PARAMETER (version 2), and if this fails, by looking up the value in PV1.3.1 in the "C" crossreference of the HOSPITAL LOCATION file, and if this fails, by using a value specified in the SISI DEFAULT VISIT LOCATION parameter. The exception is recorded when all attempts to resolve the visit's location fail. ROUTINE: SISIADTO 124

125 CODE: A02: OPT VSIT failed SHORT DESCRIPTION: The ~VSIT api wrapper returned an error for an outpatient visit. When the ADT Filer resolves required elements for editing an outpatient visit it invokes the ^VSIT api (from certain events, such as ADT-A02). The ADT Filer's wrapper for this API may record an exception, or an error returned by the VistA API itself. Or, the wrapper may not record an error. However, if the API fails to return a visit IEN, the current exception will be recorded (in the outpatient context). ROUTINE: SISIADTO CODE: A02~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A02 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A02 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A03: No matching ADM SHORT DESCRIPTION: The inpatient discharge event processor could not find a matching admission. While processing an inpatient discharge event the ADT Filer could not identify an admission movement for the same patient and the referenced admission date/time. This exception should not occur unless the patient was not previously admitted to inpatient status in VistA, or an internal movement pointer or index for the patient is invalid. ROUTINE: SISIADT3 CODE: A03: OPT DDT missing SHORT DESCRIPTION: Required discharge date/time missing from outpatient discharge event The ADT Filer could not find the discharge date/time in PV1.45, or in some cases EVN.3 or EVN.2. Therefore the outpatient discharge could not be processed. ROUTINE: SISIADTO CODE: A03: Unknown class SHORT DESCRIPTION: Implementation-specific discharge event for unsupported patient class (PV1.2). The discharge could not be processed because either the patient class PV1.2 was missing or was an unknown type in this implementationspecific context. ROUTINE: SISIADTK CODE: A03~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A03 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A03 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A04: Invalid class 125

126 SHORT DESCRIPTION: Implementation-specific register event for unsupported patient class (PV1.2). The register or admit event could not be processed because either the patient class PV1.2 was missing or was an unknown type in this implementation-specific context. ROUTINE: SISIADTK CODE: A04~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A04 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A04 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A05: K Invalid ADT SHORT DESCRIPTION: Implementation-specific outpatient pre-admit failed for invalid "Expected" date. This event requires the 'Expected admit date' in PV2.8. If this date is missing or invalid, the event cannot be processed. Note that this exception applies only in an implementation-specific context. ROUTINE: SISIADTK CODE: A05: K Invalid VLOC SHORT DESCRIPTION: Implementation-specific outpatient pre-admit failed for invalid visit location. This event requires a valid visit location in one of the usual message fields, as specified in the SISIADT HL7 INTERFACE PARAMETER file or in the default visit location computation, which depends on a File 44 "C" index lookup. ROUTINE: SISIADTK CODE: A05: K REG failed SHORT DESCRIPTION: Implementation-specific registration failed for this preadmit event. The patient was not previously known to VistA and new patient registration failed. This exception occurs only in an implementationspecific context, in which the registration depends on identifying the message sender. It uses the File HEALTH RECORD NO. multiple. ROUTINE: SISIADTK CODE: A05: K VSIT failed SHORT DESCRIPTION: Implementation-specific pre-admit VISIT entry could not be created. This exception occurs in the context of an implementation-specific outpatient pre-admit, in which the ^VSIT api is called (via the ADT Filer's wrapper) to create a visit. This call failed. If no previous relevant exception was recorded, the failure probably occurred in the API itself. ROUTINE: SISIADTK CODE: A05: Opt not impl. SHORT DESCRIPTION: Outpatient pre-admit is not implemented in this context. Except for implementation-specific rules, the ADT Filer does not process outpatient pre-admit events (ADT-A05, PV1.2='O'). 126

127 ROUTINE: SISIADTO CODE: A05: Unknown class SHORT DESCRIPTION: Implementation-specific pre-admit for an unsupported patient class (PV1.2). The pre-admit could not be processed because either the patient class (PV1.2) was missing or was of an unsupported type for this implementation-specific event. ROUTINE: SISIADTK CODE: A05~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A05 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A05 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A06: Invalid class SHORT DESCRIPTION: Change outpatient to inpatient specifies a non-inpatient class (PV1.2) The event could not be processed because the message specifies a patient class other than "I". In this implementation-specific context, the outpatient to inpatient class change must specify patient class "I" for inpatient. ROUTINE: SISIADTK CODE: A06: Invalid PV1.2 SHORT DESCRIPTION: Change outpatient to inpatient specifies a non-inpatient class (PV1.2) The event could not be processed because the message specifies patient class as "O" for outpatient, which contradicts the meaning of the event (outpatient to inpatient class change). ROUTINE: SISIADT6 CODE: A06~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A06 event processor was reached. >This exception is a place-marker, indicating that the implementationspecific ADT-A06 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A07: Invalid class SHORT DESCRIPTION: Change inpatient to outpatient specifies a non-outpatient class (PV1.2) The event could not be processed because the message specifies a patient class other than "O". In this implementation-specific context, the inpatient to outpatient event must specify patient class "O" for outpatient. ROUTINE: SISIADTK CODE: A07: Invalid PV1.2 SHORT DESCRIPTION: Change inpatient to outpatient specifies inpatient class (PV1.2). The event could not be processed because the message specifies 127

128 patient class "I" for inpatient, which contradicts the meaning of the event (outpatient to inpatient class change). ROUTINE: SISIADT7 CODE: A07~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A07 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A07 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A08: (Inp) No adm SHORT DESCRIPTION: Account admission not found when processing inpatient update event. While processing an ADT-A08 update for an inpatient admission datetime, the admission to be updated could not be found in the account transaction history. ROUTINE: SISIADT8 CODE: A08: (Opt) No adm SHORT DESCRIPTION: Visit not found when processing outpatient update event. >While processing an ADT-A08 update for an outpatient visit date-time, the visit to be updated could not be found in the account transaction history. ROUTINE: SISIADT8 CODE: A08: Bad DFN SHORT DESCRIPTION: Patient identified in update event is not the same as patient in movement. This exception reflects a sanity-check failure in the inpatient admit date/time update processor. The identified patient is not the same as the patient pointed-to by the movement to be updated. ROUTINE: SISIADT8 CODE: A08: New MRN exists SHORT DESCRIPTION: Attempt to change a patient's MRN to that of another existing patient. In update event processing, the patient is identified first by account number. The update may then change the patient's MRN to a new MRN. However, before making this change the ADT Filer checks whether the MRN is already in use, i.e. assigned to another patient, and aborts the MRN update if this is the case. This exception can also occur if an implementation-specific test for duplicate MRN returns an affirmative result. ROUTINE: SISIADT8 CODE: A08: No account SHORT DESCRIPTION: Update failed because the patient account could not be identified. This is a sanity-check exception that should not occur in the normal ADT Filer context, where the account IEN always exists. However, it might occur in some unusual context, such as for example, when chaining an ADT update to the processing of a financial 128

129 message. ROUTINE: SISIADT8 CODE: A08: No account DFN SHORT DESCRIPTION: Patient ID could not be resolved from the account number (update event). The patient could not be identified by account number, but might be identified by primary patient ID (usually MRN). ROUTINE: SISIADT8 CODE: A08: No DFN SHORT DESCRIPTION: Primary patient ID could not be resolved (update event). Although classified as 'informational' this exception prevents the patient information update. The patient could not be identified, either by account number or by primary patient ID (usually MRN). ROUTINE: SISIADT8 CODE: A08: not implemented SHORT DESCRIPTION: Patient information update is not implemented. This exception will only occur if the ADT-A08 event processor is intentionally disabled for testing. ROUTINE: SISIADT8 CODE: A08~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A08 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A08 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A10-K not impl. SHORT DESCRIPTION: This implementation-specific patient arriving event is not implemented. In this implementation-specific context, the ADT-A10 'patient arriving' event is not implemented. ROUTINE: SISIADTK CODE: A10: OPT Invalid Loc SHORT DESCRIPTION: Patient (visit) location could not be determined for 'patient arriving' event. In this event context, patient location is determined first from PV2.8, second from PV1.44, and if both fail, from the SISI DEFAULT VISIT LOCATION parameter value. If all fail, the 'patient arriving' event cannot be processed. Note that this event is supported only on an implementation-specific basis. ROUTINE: SISIAA10 CODE: A10~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A10 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A10 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. 129

130 ROUTINE: SISIADTK CODE: A10~SISIADTM No IENS SHORT DESCRIPTION: Patient could not be identified by account number. This implementation-specific 'patient arriving' event requires that the patient be identified by account number, meaning that the patient must have been registered previously, and that the account must identify the patient. ROUTINE: SISIAA10 CODE: A11 Bad mvmt context SHORT DESCRIPTION: Attempt to cancel an admission that had subsequent active movements This exception indicates that a preliminary check revealed that the last movement on record for the account was not an admission movement, and that therefore the admission movement cannot be canceled. It is necessary to cancel movements in the inverse order in which they were created. For example, if an admission is followed by a transfer, the transfer must be canceled before the admission can be canceled. ROUTINE: SISIADT1 CODE: A11 requires autoptf SHORT DESCRIPTION: Inpatient ADT-A11 failed because the configuration is invalid. The AUTO-CREATE PTF field of the SISIADT HL7 INTERFACE PARAMETER file entry must be set to YES in order to cancel an admission. The reason is that admissions must have at least a stub PTF entry in order to be edited or cancelled (in effect to be selected for editing or cancelling). This is true also in VistA bed control menus. ROUTINE: SISIADT1 CODE: A11: Invalid class SHORT DESCRIPTION: Class is not "I" or "O" for implementation-specific cancel admit event. This implementation-specific event processing requires that the ADT-A11 patient class be either "I" for cancel inpatient admit, or "O" for cancel outpatient admit. Other classes, such as "E" are not recognized. ROUTINE: SISIADTK CODE: A11: Pt. class check SHORT DESCRIPTION: ADT Filer is performing a patient class check for a cancel admit event. If the visit IEN was not found in the transaction history (by way of $$GETX^SISIAPI), the ADT Filer will perform a class check, in case the cancel- event refers to a pre-admit or etc. ROUTINE: SISIADTO CODE: A11: VISIT not found SHORT DESCRIPTION: Visit could not be cancelled because VISIT entry was not found. Although this exception is 'informational' no visit was cancelled, as no visit (for the account) could be found. ROUTINE: SISIADTO CODE: A11~SISIADTC reached 130

131 SHORT DESCRIPTION: 'Cancel admission' sub-processor of cancel inpatient events code reached. ROUTINE: SISIADTC CODE: A11~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A11 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A11 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A12: cancel ASIH xfr SHORT DESCRIPTION: The ADT Filer cannot cancel an ASIH transfer (not implemented). The ADT-A12 cancel transfer processing code determined that the ASIH SEQUENCE for the movement was not zero. While it is possible in principle to cancel this movement, the ADT Filer does not implement this function. ROUTINE: SISIADT2 CODE: A12: No prior mvmnt SHORT DESCRIPTION: Request to cancel transfer failed because no prior movements were found. The cancel transfer event processing code uses the ACCOUNT NUMBER file TRANSACTION CONTROL ID multiple, by way of the $$PREVXA^SISIACCT api, to determine the last transfer (or admission) preceding the specified patient movement. It is necessary to identify the movement that preceded the cancelled transfer in order to restore values for patient location, etc. that were in effect before the original transfer took place. ROUTINE: SISIADTC CODE: A12: not implemented SHORT DESCRIPTION: Cancel transfer event processing is disabled. This exception can only occur if the ADT-A12 processing code is intentionally disabled for testing. ROUTINE: SISIADT2 CODE: A12: xfr not found SHORT DESCRIPTION: Request to cancel transfer failed because the transfer was not found. The ADT-A11 cancel transfer processing code could not identify a non-asih transfer movement to cancel. This process uses the PATIENT MOVEMENT file's ADFN cross-reference, screening by TRANSACTION. ROUTINE: SISIADT2 CODE: A12~SISIADTC reached SHORT DESCRIPTION: 'Cancel transfer' sub-processor of cancel inpatient events code reached. ROUTINE: SISIADTC CODE: A12~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A12 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A12 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface 131

132 configuration phase. ROUTINE: SISIADTK CODE: A13: VISIT not found SHORT DESCRIPTION: Cancel outpatient discharge failed because the discharged visit was not found. The outpatient ADT-A13 handler deletes the CHECK OUT DATE&TIME from a visit. To identify the discharged visit it traverses the ACCOUNT NUMBER : TRANSACTION CONTROL ID multiple using the $$GETX^SISIAPI call. This call screens visits by patient class. Thus, only a visit pointer for an outpatient transaction will satisfy the requirement to cancel the discharged visit. ROUTINE: SISIADTO CODE: A13~SISIADTC reached SHORT DESCRIPTION: 'Cancel discharge' sub-processor of cancel inpatient events code reached. ROUTINE: SISIADTC CODE: A13~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A13 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A13 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A17: Bad DFN or DFN2 SHORT DESCRIPTION: One of the patients could not be identified for a SWAP BEDS transaction. The ADT-A17 event interface (IMPLEMENTATION-SPECIFIC API preprocessor) requires that both patients be identified in the HL7 message, i.e. that both be resolvable by the COMPUTE DFN and PATIENT (2) DFN fields in the SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIAMSC CODE: A21~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A21 event processor was reached. This exception is a place-marker, indicating that the implementation- >specific ADT-A21 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A22~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A22 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A22 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A28: Patient Exists SHORT DESCRIPTION: Patient previously exists in database, for 'add person information' event. 132

133 This exception is reported because ADT-A28 generally reports data for a new person (patient), while ADT-A31 reports updated information for an existing person (patient). The processing context may, however, permit A28 to update an existing patient's information, or an A31 to create a new person record. This exception is only important, if the processing rules disallow updating an existing patient record from an ADT-A28. ROUTINE: SISIADTM CODE: A28~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A28 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A28 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A28~SISIADTM No IENS SHORT DESCRIPTION: ADT-A28 failed because patient was not found and could not be registered. The 'Add Person Information' processor expects to register a new patient. If patient lookup fails AND registration fails for any reason, this exception is recorded (on return from registration). ROUTINE: SISIADTM CODE: A31~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A31 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A31 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A31~SISIADTM No IENS SHORT DESCRIPTION: Patient lookup failed for 'Update Person Information' event. This exception is similar to the A28~SISIADTM No IENS exception, except that the update processor does not attempt to register the patient as a new patient. The patient is expected to have been previously registered, and if COMPUTE DFN fails, this exception is recorded. ROUTINE: SISIADTM CODE: A36-K not impl. SHORT DESCRIPTION: Merge patient information is not supported in the K-events context. The ADT Filer does not support processing for the ADT-A36 event in this context. ROUTINE: SISIADTK CODE: A36: ~XMD Error SHORT DESCRIPTION: Attempt to send a bulletin failed. Routine ~XMD returned an error. An ordinary ADT-A36 event by default sends a bulletin to the G.SISIADT A36 mail group. This exception indicates that the VistA bulletin processor in Mailman returned an error. The expanded exception record (viewed through Fileman) should contain 133

134 additional information about the failure. ROUTINE: SISIADTX CODE: A36~SISIADTK reached SHORT DESCRIPTION: Implementation-specific A36 event processor was reached. This exception is a place-marker, indicating that the implementationspecific ADT-A36 event processor in routine SISIADTK was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTK CODE: A38~duplicate cancel SHORT DESCRIPTION: Cannot cancel a previously cancelled pre-admit The ADT-A38 event processor found that the scheduled admission to be cancelled had previously been cancelled. The originally recorded cancel date/time is not changed. ROUTINE: SISIA38 CODE: A47 DFN not found SHORT DESCRIPTION: Could not compute the patient DFN, based on CHANGE PPID DFN logic. The ADT-A47 event processor attempts to identify the patient whose primary ID will be changed, using logic defined in the CHANGE PPID DFN field of File This logic failed to identify an existing patient, from data in the current HL7 message. ROUTINE: SISIA47 CODE: A47 Invalid context SHORT DESCRIPTION: Attempt to process ADT-A47 failed due to context. The ADT Filer only partially implements ADT-A47 processing. If the configuration includes an implementation-specific REGISTER PATIENT api, ADT-A47 event messages cannot be processed. ROUTINE: SISIA47 CODE: A47 New PPID exists SHORT DESCRIPTION: Target primary patient ID belongs to an existing VistA patient. The primary patient ID as defined in the COMPUTE DFN field of File resolves to an existing VistA patient. Hence the ADT-A47 patient (identified by the CHANGE PPID DFN field) cannot be changed to the "new" PPID. A patient's primary ID can only be changed to an ID that is not already in use by another patient. ROUTINE: SISIA47 CODE: A47 PPID field map SHORT DESCRIPTION: A Primary Patient ID field map was not found. ADT-A47 processing code requires a Primary Patient ID entry in the SISIADT AUXILIARY FIELD MAP file to exist, and to be referenced in File ROUTINE: SISIA47 CODE: A47 PPID map IENS SHORT DESCRIPTION: Primary patient ID field map does not refer to variable SISIDFN. 134

135 The ADT-A47 event processing code requires the SISIADT AUXILIARY FIELD MAP entry that defines the Primary Patient ID to use the variable SISIDFN to define the entry to be modified. Thus only the PATIENT file or a file that is DINUM'ed to the PATIENT file can be referenced in this context. Note that this execption applies only in the ADT-A47 context. It does not preclude the use of other identification schemes in other contexts. ROUTINE: SISIA47 CODE: A47 PPID replaced SHORT DESCRIPTION: The ADT-A47 event was successfully processed. PPID was changed. This informational exception indicates that the verification test using COMPUTE DFN succeeded on the new PPID, after replacement. ROUTINE: SISIA47 CODE: A47 Repl PPID failed SHORT DESCRIPTION: Attempt to file a replacement primary patient ID failed for unknown reasons. All preliminary checks passed and an attempt was made to file a replacement value for the Primary Patient ID. However, after filing, the COMPUTE DFN logic failed on the new PPID, indicating either that it was not filed or that some problem prevents the verification lookup from succeeding. ROUTINE: SISIA47 CODE: Adm: Mvt DT conflict SHORT DESCRIPTION: The admission date/time conflicts with a previous discharge d/t for the patient. While processing an admission, a check reveals that the admission date/time is the same as a discharge date/time of an existing movement for the same patient. This exception is currently not fatal, but is recorded in NORMAL log status mode, and requires corrective action. In most cases the corrective action will be to edit the existing discharge date/time. However, the most appropriate action cannot be specified in advance for each case, as this requires study of the complete context of the event. ROUTINE: SISIADT1 CODE: Adm: Mvt DT failure SHORT DESCRIPTION: The admit date/time failed one or more movement chronology checks. When the parameter SISI RESTRICT ADMIT DATE/TIME is valued YES (true), one or more additional checks are performed on inpatient admit date/time, to prevent if possible an out-of-sequence admission movement. These checks may be expanded in future ADT Filer patches. However, checks are not performed and this exception cannot occur, if the SISI RESTRICT ADMIT DATE/TIME parameter is valued NO or is not valued. ROUTINE: SISIADT1 CODE: ADMIEN~SISIACCT fail SHORT DESCRIPTION: Attempt to compute admission movement IEN from transaction 135

136 history failed. The $$ADMIEN^SISIACCT(<admit date>) api attempts to determine the admission movement IEN from the ACCOUNT NUMBER : TRANSACTION CONTROL ID multiple. If the admit date is included in the call, an exact match is required. Whether or not admit date must match depends upon the calling context. ROUTINE: SISIACCT CODE: ADT-A01 Disabled SHORT DESCRIPTION: ADT-A01 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A02 Disabled SHORT DESCRIPTION: ADT-A02 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A03 Disabled SHORT DESCRIPTION: ADT-A03 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A04 Disabled SHORT DESCRIPTION: ADT-A04 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A06 Disabled SHORT DESCRIPTION: ADT-A06 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A07 Disabled SHORT DESCRIPTION: ADT-A07 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A08 Disabled SHORT DESCRIPTION: ADT-A08 event processing is not enabled in SISIADT HL7 INTRFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A11/A01 Disabled SHORT DESCRIPTION: ADT-A11 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A12/A02 Disabled SHORT DESCRIPTION: ADT-A12 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A13/A03 Disabled SHORT DESCRIPTION: ADT-A13 event processing is not enabled in SISIADT HL7 INTERFACE PARAMETER file. ROUTINE: SISIADT0 CODE: ADT-A21 Disabled SHORT DESCRIPTION: Implementation-specific ADT-A21 event processing is not enabled. ROUTINE: SISIADT0 136

137 ROUTINE: SISIADTK CODE: ADT-A22 Disabled SHORT DESCRIPTION: Implementation-specific ADT-A22 event processing is not enabled. ROUTINE: SISIADT0 ROUTINE: SISIADTK CODE: ADT~SISIACCT failed SHORT DESCRIPTION: Attempt to compute inpatient admission date/time for current account failed. This exception is reported by the $$ADT^SISIACCT (private) API, that computes the inpatient admission date/time for the account number of the current HL7 message. If no previous transaction for the account points to an admission movement, the exception is recorded. ROUTINE: SISIACCT CODE: ADTOK: Invalid parm SHORT DESCRIPTION: An invalid parameter (DFN or admit D/T) was argued to the $$ADTOK function. This exception should not be seen in normal ADT Filer usage. It was created primarily for testing the $$ADTOK^SISIAV25 extrinsic function in artifical contexts, in which the function's required parameters may not have been properly defined. ROUTINE: SISIAV25 CODE: ALL~SISIAGU Param Er SHORT DESCRIPTION: Auxiliary field map processing failed because the event driver was not found. This exception should not occur under any ordinary circumstance. It is basically a sanity check on the environment for post-processing of auxiliary field map entries. It must be possible to identify the event driver protocol of the current message. ROUTINE: SISIAGU CODE: APHY External SHORT DESCRIPTION: Deprecated exception formerly reported attending physician PV1.7.1 value. ROUTINE: SISIADTS CODE: APHY VistA SHORT DESCRIPTION: Deprecated exception formerly reported attending physician IEN. ROUTINE: SISIADTS CODE: Application inactive SHORT DESCRIPTION: The ADT Filer HL7 interface application SISIADT FILER is not active. ROUTINE: SISIADT CODE: APRV: No external ID SHORT DESCRIPTION: Attempt to compute attending provider failed because PV1.7.1 has no data. The ADT Filer computes attending provider according to the rule specified in the COMPUTE ATTENDING PROVIDER parameter (File 29320). If this fails, the ADT Filer falls through to a default computation that depends upon data in PV If this fails, the current 137

138 exception is reported. ROUTINE: SISIAV2 CODE: ASIH +30 dsc failed SHORT DESCRIPTION: The +30 day pseudo-discharge component of an ASIH sequence failed. This exception may be either informational or fatal. It indicates that an error occurred while attempting to create the +30 day pseudo-discharge from long-term care, while processing a to-asih sequence. ROUTINE: SISIASIH CODE: ASIH No current adm SHORT DESCRIPTION: 'To ASIH' failed because the PATIENT file entry does not have an admission. The context is generic 'To ASIH' processing, i.e. not implementationspecific. The event handler attempts to identify the current admission from the File 2 field #.105 (CURRENT ADMISSION) pointer. No value was found for the current admission. ROUTINE: SISIASIH CODE: ASIH spc xfr failed SHORT DESCRIPTION: The specialty transfer component of an ASIH sequence failed. This exception may be either informational or fatal. It indicates that an error occurred while attempting to create the specialty transfer movement component of a to-asih sequence. ROUTINE: SISIASIH CODE: Axx~SISIADT0 reached SHORT DESCRIPTION: Indicates that the named event processing entry point was reached. A group of very verbose exceptions 'Axx~SISIADT0 reached' have been added, in some cases replacing exceptions of the form 'Dequeue Axx~SISIADT' and in some cases new. These exceptions are place markers, indicating that the main entry point for processing the named event was reached. Normally this point is reached in the background, when Taskman dequeues the event processing task. One exception of the form 'UNK~SISIADT0 reached' indicates that the specified event type is not supported by the ADT Filer. This exception should not be recorded, unless the ADT Filer code is reached in an unconventional way, such as through a user-defined protocol. ROUTINE: SISIADT0 CODE: Call ARM DFN=<IEN> SHORT DESCRIPTION: Calling API to delete "ARM" (room-bed) index for patient <IEN>. ROUTINE: SISIADTC CODE: Cannot admit lodger SHORT DESCRIPTION: Event could not be processed because patient is a lodger. This exception code is somewhat misleading, as the event processing context is ADT-A02 'transfer patient'. However, the basic sense is the same as in the admission context, namely that the event cannot 138

139 be processed because the patient is a lodger. The ADT Filer does not support transferring a lodger. ROUTINE: SISIADT1 ROUTINE: SISIADT2 CODE: Cannot compute DFN SHORT DESCRIPTION: The patient internal entry number could not be computed. This exception occurs when a discharge event refers to a patient whose entry cannot be resolved from the patient ACCOUNT NUMBER entry, by way of the DFN^SISIACCT api. ROUTINE: SISIADT3 CODE: Chain Events No DFN SHORT DESCRIPTION: Attempt to unwind SISIA MOVEMENT EVENTS failed because patient DFN was invalid. After processing an inpatient movement event, the post events processor could not find the patient IEN, either in variable DFN or SISIDFN. Therefore the movement events were not unwound. ROUTINE: SISIADBA CODE: Class: <PV1.2> SHORT DESCRIPTION: Deprecated exception formerly reported patient class for post events. ROUTINE: SISIADBA CODE: Cncl pre-admt no DFN SHORT DESCRIPTION: ADT-A38 (cancel pre-admit) failed because the patient IEN could not be computed. The ADT Filer computes patient IEN (DFN) from the account number, when processing an ADT-A38, i.e. using the private API DFN^SISIACCT, which may also use additional data to resolve the patient ID. While the pre-admit was not cancelled, this particular exception is presently reported as informational. That is probably because no portal is currently defined for ADT-A38 processing. ROUTINE: SISIADT5 CODE: Cncl pre-admt No sch SHORT DESCRIPTION: Attempt to cancel inpatient pre-admit failed because scheduled admit not found. No scheduled admission was found in File 41.1 to match the cancel pre-admit request. Therefore the cancel or discharge could not be processed. ROUTINE: SISIADT5 CODE: Computed APRV <NAME> SHORT DESCRIPTION: Value returned by COMPUTE ATTENDING PROVIDER method (VistA NAME). ROUTINE: SISIAV2 CODE: Computed PPRV <NAME> SHORT DESCRIPTION: Value returned by COMPUTE PRIMARY PROVIDER method (VistA NAME). ROUTINE: SISIAV2 CODE: Computed provider ID SHORT DESCRIPTION: Exception data contains computed provider ID. ROUTINE: SISIAV2 CODE: Dequeue A01~SISIADT 139

140 SHORT DESCRIPTION: ADT-A01 event handler reached. ROUTINE: SISIADT0 CODE: Dequeue A05~SISIADT SHORT DESCRIPTION: ADT-A05 event handler reached. ROUTINE: SISIADT0 CODE: Dequeue A06~SISIADT SHORT DESCRIPTION: ADT-A06 event handler reached. ROUTINE: SISIADT0 CODE: Dequeue A07~SISIADT SHORT DESCRIPTION: ADT-A07 event handler reached. ROUTINE: SISIADT0 CODE: Dequeue P01~SISIABAR SHORT DESCRIPTION: BAR-P01 event handler reached. ROUTINE: SISIABAR CODE: Dequeue P05~SISIABAR SHORT DESCRIPTION: BAR-P05 event handler reached. ROUTINE: SISIABAR CODE: Dequeue S12~SISIADT SHORT DESCRIPTION: SIU-S12 event handler reached. ROUTINE: SISIASIU CODE: Dequeue S12~SISIAPPT SHORT DESCRIPTION: Make appointment sub-processor reached. ROUTINE: SISIAPPT CODE: Dequeue S13~SISIADT SHORT DESCRIPTION: Reschedule appointment sub-processor reached. ROUTINE: SISIASIU CODE: Dequeue S13~SISIAPPT SHORT DESCRIPTION: Reschedule appointment sub-processor reached. ROUTINE: SISIAPPT CODE: Dequeue S14~SISIADT SHORT DESCRIPTION: Modified appointment sub-processor reached. ROUTINE: SISIASIU CODE: Dequeue S14~SISIAPPT SHORT DESCRIPTION: Modified appointment sub-processor reached. ROUTINE: SISIAPPT CODE: Dequeue S15~SISIADT SHORT DESCRIPTION: Cancelled appointment sub-processor reached. ROUTINE: SISIASIU CODE: Dequeue S15~SISIAPPT SHORT DESCRIPTION: Cancelled appointment sub-processor reached. ROUTINE: SISIAPPT CODE: Dequeue S17~SISIAPPT SHORT DESCRIPTION: Deleted appointment sub-processor reached. ROUTINE: SISIAPPT CODE: Dequeue S26~SISIAPPT SHORT DESCRIPTION: Appointment 'no show' sub-processor reached. ROUTINE: SISIAPPT 140

141 CODE: DGPMVI undefined SHORT DESCRIPTION: Inpatient data not accessible for patient movement processing. This exception should not occur, as it reflects entering the discharge movement processor, without a valid context. The movement processor could not obtain an inpatient data array, which generally means the patient is not an inpatient, and therefore would not have reached this point in the process. ROUTINE: SISIADT1 ROUTINE: SISIADT3 CODE: Dis: Mvt DT conflict SHORT DESCRIPTION: The discharge date/time conflicts with an existing admission DT for the patient. While processing a discharge event, a check reveals that the date/time is the same as the admission date/time of an existing movement for the same patient. This exception is currently not fatal, but is recorded in NORMAL log status mode, and requires corrective action. In most cases the corrective action will be to edit the discharge date/time. However, the most appropriate action to take in each case cannot be specified in advance, i.e., without study of the event's context and associated movements. ROUTINE: SISIADT3 CODE: Disallow future VSIT SHORT DESCRIPTION: Parameter setting disallowed creation of a future outpatient visit. The parameter SISI DISALLOW FUTURE OPT VISIT controls creation of future outpatient visits. If this parameter prevents creation of a visit that would otherwise be created by the event, the present exception is recorded (in very verbose mode only). ROUTINE: SISIAUT2 CODE: Disallow future VSIT SHORT DESCRIPTION: Parameter setting disallowed creation of a future outpatient visit. The parameter SISI DISALLOW FUTURE OPT VISIT controls creation of future outpatient visits. If this parameter prevents creation of a visit that would otherwise be created by the event, the present exception is recorded (in very verbose mode only). ROUTINE: SISIAUT2 CODE: Disallow future VSIT SHORT DESCRIPTION: Parameter setting disallowed creation of a future outpatient visit. The parameter SISI DISALLOW FUTURE OPT VISIT controls creation of future outpatient visits. If this parameter prevents creation of a visit that would otherwise be created by the event, the present exception is recorded (in very verbose mode only). ROUTINE: SISIAUT2 CODE: Disallow MRN update SHORT DESCRIPTION: MRN update was disallowed by parameter setting (ADT-A08) In the ADT-A08 event processing context, MRN (patient primary ID) updating is disallowed by the setting of parameter SISI DISALLOW A08 MRN UPDATE. An update may or may not have otherwise occurred. This check is performed before other checks that would determine 141

142 whether or not the MRN should be updated. ROUTINE: SISIADT8 CODE: Dsch: never admitted SHORT DESCRIPTION: Cannot process inpatient discharge for patient who was never admitted. This exception is unlikely to occur, due to other screens which would prevent the event processor from reaching the point where prior admissions are checked in the APTT1 cross-reference of the patient movement file. If the patient has no prior admissions, this exception is recorded. ROUTINE: SISIADT3 CODE: Dup Inpt Admission SHORT DESCRIPTION: Cannot create admission if the patient is currently admitted in VistA This exception can occur in several different contexts. For example, a patient may have been admitted as an outpatient in the sending system, but as an inpatient in VistA (due to different classification of the patient location or etc). A subsequent change to inpatient status on the sending system generates an A01 or an A06, which is interpreted as a duplicate inpatient admission in VistA. This exception can also arise when a 'cancel discharge' event is received, but the patient is currently an active inpatient in VistA, i.e. not discharged from inpatient status in VistA. By definition a patient who is discharged is not currently admitted. Canceling the discharge reactivates the previous admission that was discharged. If the patient is currently admitted, activating the previous admission would be equivalent to creating a duplicate inpatient admission, which is not allowed. ROUTINE: SISIADT1 ROUTINE: SISIADT3 CODE: Dup Inpt Discharge SHORT DESCRIPTION: Inpatient discharge cannot be processed for patient who is already discharged. An inpatient discharge can only be processed for a patient who is currently admitted. If the patient not currently admitted, due to having been discharged previously, the current discharge event cannot be processed, as it would create a duplicate discharge movement. ROUTINE: SISIADT3 CODE: Dup. movement DT SHORT DESCRIPTION: Admission or discharge movements for the same patient have the same date/time. This exception is recorded when two or more PATIENT MOVEMENT admission or discharge transactions for the same patient have the same #.01 field DATE/TIME value. When this exception occurs, it is likely that a discharge movement will point to the wrong corresponding admission. Note that the ADT Filer does not support duplicate movement DATE/TIME values for admission and discharge movements (for the same patient). Specialty transfer movements and other special cases (to- /from- ASIH) may have the same movement DATE/TIME values, but episodes of care must not overlap. 142

143 The requirement of non-overlapping inpatient episodes of care means that the second admission must strictly follow the first discharge. Likewise the third admission must follow the second discharge, and so forth. A new admission may not begin on or before the last preceding discharge. ROUTINE: SISIAUTL CODE: Editing opt location SHORT DESCRIPTION: The update event will attempt to modify the outpatient visit location. ROUTINE: SISIADT8 CODE: EN~SISIABAR(<MSG>,<EVN>) SHORT DESCRIPTION: Main BAR message processor reached. ROUTINE: SISIABAR CODE: EN~SISIADT(<MSG>,<EVN>) SHORT DESCRIPTION: Main ADT message processor reached (ADT Filer processing routine). ROUTINE: SISIADT CODE: EN~SISIADTI No msg SHORT DESCRIPTION: Field map processing failed because HL7 message was not found. This is a sanity-check exception in the multi-event wrapper for processing mapped fields (auxiliary field map entries). It means that the parsed message could not be found, which would generally indicate that some corruption has occurred within the process. ROUTINE: SISIADTI CODE: EN~SISIADTI reached SHORT DESCRIPTION: The auxiliary field map processor was reached. This exception is a place-marker, indicating that the auxiliary field map processor was reached. This processing PRECEDES the post-events protocol-based processing, such as movement events, update events, etc. ROUTINE: SISIADTI CODE: EN~SISIAGU Param Er SHORT DESCRIPTION: Field map processing failed because protocol or segment was not found. This is a sanity-check exception in the auxiliary field map processor. It means that the protocol or HL7 segment to be processed could not be identified, which would generally indicate a basic configuration issue or invalid context for the ADT Filer. ROUTINE: SISIAGU CODE: EN~SISIAPPT(<MSG>,<EVN>) SHORT DESCRIPTION: Main appointment events (SIU message) processor reached. ROUTINE: SISIAPPT CODE: EN~SISIASIU(<MSG>,<EVN>) SHORT DESCRIPTION: Main appointment events (SIU message) processor reached. ROUTINE: SISIASIU CODE: Error in ~DGPMVDL[1] SHORT DESCRIPTION: Cancel failed due to error in called procedure. 143

144 The cancel movement processor calls bed control routines at various (unsupported) entry points. One of these calls returned an error indicating that the cancel event could not be processed. ROUTINE: SISIADTC CODE: Event: <EVN> SHORT DESCRIPTION: Post events processing reached for the identified event type. ROUTINE: SISIADBA CODE: EVN: ACKONLY~SISIADT SHORT DESCRIPTION: Event type EVN was processed by the ACK only handler. The event type EVN (stands for any event type) was not processed by a normal ADT Filer event handler. In other words no message data were processed to VistA. A special handler, processed the message acknowledgement (if required) and nothing else. ROUTINE: SISIADT CODE: External provider ID SHORT DESCRIPTION: Lookup provider by method in field #11 or #12 in File See also data. ROUTINE: SISIAV2 CODE: File 43 undefined SHORT DESCRIPTION: The MAS PARAMETERS file does not exist. This exception should not occur, as it relates to a basic VistA configuration issue. The MAS PARAMETER file must exist and have appropriate values in order to process patient movements in VistA, either manually or via HL7 messaging. ROUTINE: SISIADT1 ROUTINE: SISIADT2 ROUTINE: SISIADT3 CODE: FrASIH DGPMCA=<IEN> SHORT DESCRIPTION: While processing 'From ASIH' the corresponding admission movement IEN is <IEN>. ROUTINE: SISIADT3 CODE: FrASIH SISIDCA=<IEN> SHORT DESCRIPTION: While processing 'From ASIH' the most recent acute care admission IEN is <IEN>. ROUTINE: SISIASIH CODE: FromASIH No +30 PMDA SHORT DESCRIPTION: Could not cancel +30 day discharge from Long Term Care. While processing a 'from ASIH' event, the ADT Filer could not find the +30 day discharge from Long Term Care, and therefore could not cancel this movement (if it exists). ROUTINE: SISIASIH CODE: FromASIH No LTC ADT SHORT DESCRIPTION: Could not transfer to Long Term Care because LTC admit date was not found. While processing a 'from ASIH' event, the ADT Filer could not find the admit date of the original Long Term Care admission, and therefore could not process the transfer movement component of 'from ASIH.' ROUTINE: SISIASIH 144

145 CODE: FromASIH No LTC PMDA SHORT DESCRIPTION: Could not identify most recent Long Term Care admission. While processing a 'from ASIH' event, the ADT Filer could not compute the corresponding Long Term Care admission movement (i.e. the one preceding the 'to ASIH' event. This computation relies on the ADFN cross-reference of the PATIENT MOVEMENT file and does not use ADT Filer's ACCOUNT NUMBER : TRANSACTION CONTROL ID record. ROUTINE: SISIASIH CODE: General error SHORT DESCRIPTION: Unspecified error while processing an inpatient admission. This error occurs in the context of processing cloned bed-control code. The exception should not occur, and the conditions would have to be examined on a case-by-case basis. Possibly installation of a patch affecting bed control might cause this error to occur. ROUTINE: SISIADT1 CODE: GNS~SISIAPNS reached SHORT DESCRIPTION: Indicates that tag GNS in routine SISIAPNS was reached. This is a place marker exception, possibly useful in debugging, to indicate that code was reached to process guarantor information from a GT1 segment as pseudo-insurance information to be filed to the PATIENT file, INSURANCE TYPE multiple. ROUTINE: SISIAPNS CODE: GT1 SPONS PERS fail SHORT DESCRIPTION: The attempt to create a SPONSOR PERSON file entry failed Additional information might be obtained by temporarily setting the LOG STATUS to level 4, as a DIERR message should have been generated for this failure. ROUTINE: SISIAGT1 CODE: GT1 SPONSOR fail SHORT DESCRIPTION: The attempt to create a SPONSOR file entry failed Additional information might be obtained by temporarily setting the LOG STATUS to level 4, as a DIERR message should have been generated for this failure. ROUTINE: SISIAGT1 CODE: GT1 to API failed SHORT DESCRIPTION: Invalid context for protocol SISIA GT1 USE IMPL-SPECIFIC API The protocol SISIA GT1 USE IMPL-SPECIFIC API provides an interface to an FILE GUARANTOR DATA implementation-specific API. Since the protocol has a screen, this exception should not occur. However, if the implementing code were invoked through some other method, i.e., not from the protocol, the code's redundant context check could fail. CODE: GT1 to IB failed SHORT DESCRIPTION: Invalid context for protocol SISIA GT1 TO IB SPONSOR implementing code This exception should not occur, because the protocol SISIA GT1 TO IB SPONSOR has a screen. However, if the implementing code were invoked through some other route, without adequate 145

146 context, this exception would be reported. ROUTINE: SISIAGT1 CODE: GT1 to RPMS failed SHORT DESCRIPTION: Invalid context for protocol SISIA GT1 TO RPMS GUARANTOR protocol This exception should not occur, because the protocol SISIA SISIA GT1 to RPMS GUARANTOR has a screen. However, it is possible that the implementing code was invoked in a non-rpms environment (or more precisely an environment that does not have File ). It is also possible, though less likely that the code was invoked in an unsupported way. ROUTINE: SISIAGT1 CODE: GT1 to RPMS not impl SHORT DESCRIPTION: The protocol SISIA GT1 TO RPMS GUARANTOR is not implemented. The RPMS GUARANTOR file only supports guarantors that are patients, insurers, or employers. Therefore this protocol's implementation has been deferred. ROUTINE: SISIAGT1 CODE: GUAR update failed SHORT DESCRIPTION: Attempt to file GUARANTOR information failed. This exception occurs after attempting to file data to the GUARANTOR file ( ). Note that this is an RPMS (IHS) file, not part of FOIA VistA. ROUTINE: SISIAINS CODE: GUARN Update failed SHORT DESCRIPTION: Guarantor data could not be filed to File (IHS). The Fileman database server api returned an error for filing data to the GUARANTOR file. ROUTINE: SISIAINS CODE: Import: No file name SHORT DESCRIPTION: Field map import failed because file name was not specified. This is not an HL7 interface exception, but occurs in the context of using a supporting utility to import field maps from a host file. The file name was not specified. ROUTINE: SISIAUT1 CODE: Import: Open failed SHORT DESCRIPTION: Field map import failed because open failed on file. This is not an HL7 interface exception, but occurs in the context of using a supporting utility to import field maps from a host file. The specified file could not be opened. ROUTINE: SISIAUT1 CODE: In A04~SISIADT4 SHORT DESCRIPTION: Register patient event ADT-A04 was reached. ROUTINE: SISIADT4 CODE: In A36~SISIADTX SHORT DESCRIPTION: Merge patient information ADT-A36 event handler reached, currently a no-op. 146

147 ROUTINE: SISIADTX CODE: In ADTI~SISIA081 SHORT DESCRIPTION: Inpatient admit date/time update processor was reached. Replaces ADTI~SISIADT8. ROUTINE: SISIA081 CODE: In ADTI~SISIADT8 SHORT DESCRIPTION: Inpatient admission date/time update sub-processor was reached. ROUTINE: SISIADT8 CODE: In ADTO~SISIA081 SHORT DESCRIPTION: Outpatient admit date/time update was reached. Replaces ADTO~SISIADT8. ROUTINE: SISIA081 CODE: In ADTO~SISIADT8 SHORT DESCRIPTION: Outpatient visit date/time update sub-processor was reached. ROUTINE: SISIADT8 CODE: In ADT~SISIADT8 SHORT DESCRIPTION: Admission date/time update processor was reached ROUTINE: SISIADT8 CODE: In Appointment Evnts SHORT DESCRIPTION: Indicates that post-appointment events processing was reached. After executing implementation-specific appointment message event processing routines or ADT Filer default appointment events routines, the SISIA APPOINTMENT EVENTS protocol unwinder was reached. ROUTINE: SISIAPPT ROUTINE: SISIASIU CODE: In APRV~SISIAV2 SHORT DESCRIPTION: Attending provider compute code reached. ROUTINE: SISIAV2 CODE: In AVS~SISIADT8 SHORT DESCRIPTION: Inpatient admission visit update processor was reached ROUTINE: SISIADT8 CODE: In CFILEID~SISIADFN SHORT DESCRIPTION: Implementation-specific 'file patient identifiers' code reached (BAR-P01). ROUTINE: SISIAP01 CODE: In DSC~SISIADT8 SHORT DESCRIPTION: Discharge date/time update processor was reached. ROUTINE: SISIADT8 CODE: In EDIT~SISIADTS SHORT DESCRIPTION: Edit specialty transfer movement fields sub-processor reached. ROUTINE: SISIADTS CODE: In FTS~SISIADT8 SHORT DESCRIPTION: Informs that the FTS (facility treating specialty) code block has been reached. This block is called from the WARD update and only files facility 147

148 treating specialty if the previous value was empty. ROUTINE: SISIADT8 CODE: In LOCO~SISIA081 SHORT DESCRIPTION: Outpatient location update processor was reached. Replaces LOCO~SISIADT8. ROUTINE: SISIA081 CODE: In LOCO~SISIADT8 SHORT DESCRIPTION: Update outpatient visit location sub-processor reached. ROUTINE: SISIADT8 CODE: In MRN~SISIADT8 SHORT DESCRIPTION: Update MRN (primary patient ID) sub-processor reached. ROUTINE: SISIADT8 CODE: In ONE~ Compute IENS SHORT DESCRIPTION: Auxiliary field map 'compute IENS' reached. ROUTINE: SISIAGU CODE: In ONE~ Define FDA SHORT DESCRIPTION: Auxiliary field map 'define file descriptor array' code reached. ROUTINE: SISIAGU CODE: In ONE~ Extract data SHORT DESCRIPTION: Auxiliary field map 'extract data' reached. ROUTINE: SISIAGU CODE: In PHY~SISIADT8 SHORT DESCRIPTION: Update provider fields sub-processor reached. ROUTINE: SISIADT8 CODE: In PNAME~SISIADT8 SHORT DESCRIPTION: Update patient name sub-processor reached. ROUTINE: SISIADT8 CODE: In PPRV~SISIAV2 SHORT DESCRIPTION: Primary provider (physician) compute code reached. ROUTINE: SISIAV2 CODE: In PROCESS~SISIAGU SHORT DESCRIPTION: The single field map entry processor was reached. This exception is a place-marker, indicating that the sub-processor for handling a single auxiliary field map entry was reached by way of the ORDER subscript. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIAGU CODE: In REG~SISIADFN ROUTINE: SISIADFN CODE: In RMBD~SISIADT8 ROUTINE: SISIADT8 CODE: In SPEC~SISIADTS SHORT DESCRIPTION: The inpatient specialty transfer movement sub-processor was reached. This exception is a place-marker, indicating that the sub-processor 148

149 for creating a specialty transfer movement associated with an admission or ASIH transfer was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTS CODE: In SSN~SISIADT8 ROUTINE: SISIADT8 CODE: In UPDFTS~SISIADT8 SHORT DESCRIPTION: Informs that the FTS (facility treating specialty) update processor was reached. This block is called in contexts where an existing facility treating specialty may be updated. ROUTINE: SISIADT8 CODE: In WARD~SISIADT8 ROUTINE: SISIADT8 CODE: Info: Chained Events ROUTINE: SISIADBA CODE: Info: Data OK ROUTINE: SISIADBA CODE: Info: OPT admission SHORT DESCRIPTION: The outpatient admission event processor was reached. This exception is a place-marker, indicating that the event handler for outpatient admissions was reached. This may result from an outpatient ADT-A01 or an inpatient to outpatient transfer (A07). The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTO CODE: Info: OPT discharge SHORT DESCRIPTION: The outpatient discharge event processor was reached. This exception is a place-marker, indicating that the event handler for outpatient discharges was reached. This may result from an outpatient ADT-A03 or and outpatient to inpatient transfer (A06). The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTO CODE: Info: OPT transfer SHORT DESCRIPTION: The outpatient transfer event processor was reached. This exception is a place-marker, indicating that the event handler for outpatient transfers was reached. This may result from an outpatient ADT-A02 event, and should result in creating a new outpatient VISIT (under normal processing rules). The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIADTO CODE: Info: Supported Evnt ROUTINE: SISIADBA CODE: Info: Test exception SHORT DESCRIPTION: This exception may be recorded from a protocol or elsewhere for testing. MAIL GROUP: SISIADT TEST 149

150 It may be helpful to have an indication when implementation-specific code is reached from a protocol or field map entry or elsewhere. This exception is for convenience use in debugging. CODE: Info: Test exception SHORT DESCRIPTION: This exception may be recorded from a protocol or elsewhere for testing. MAIL GROUP: SISIADT TEST It may be helpful to have an indication when implementation-specific code is reached from a protocol or field map entry or elsewhere. This exception is for convenience use in debugging. CODE: Info: Test exception SHORT DESCRIPTION: This exception may be recorded from a protocol or elsewhere for testing. MAIL GROUP: SISIADT TEST It may be helpful to have an indication when implementation-specific code is reached from a protocol or field map entry or elsewhere. This exception is for convenience use in debugging. CODE: Info: UPDATE Events ROUTINE: SISIADBA CODE: Inp ADM VISIT failed SHORT DESCRIPTION: The VISIT entry for an inpatient admission could not be created. Inpatient admissions result in both a PATIENT MOVEMENT file entry and a VISIT file entry. The movement entry points to the visit. The most common cause of visit failure is an invalid, i.e. unresolvable visit location. While the inpatient Ward location is computed from File 42, the visit location is generally computed from File 44. Check the consistency of data against the compute code for visit location in File By default, (if no other method is specified), the ADT Filer uses the "C" cross-reference of File 44 to lookup the (optionally translated) message visit location code. ROUTINE: SISIADT1 CODE: Insufficient data SHORT DESCRIPTION: Post-event processing terminated due to insufficient data. This exception can occur for an inpatient event A01, A02, A03, or A06, after event processing is complete and before post-movement events are unwound. The exception means that insufficient data exist to perform post-movement events processing. For example, the movement IEN may not exist. ROUTINE: SISIADBA CODE: INSURER not found SHORT DESCRIPTION: Insurance company name was not found in the INSURER file. An attempt to lookup the insurance company name in the INSURER file ( ) failed. Note that this is an RPMS (IHS) file, not included in FOIA VistA. ROUTINE: SISIAPNS ROUTINE: SISIAINS CODE: INSURER unk type SHORT DESCRIPTION: Type of insurer could not be determined from File

151 Field #.21 in the INSURER file did not have a value. Therefore, the insurance type (for filing to IHS files) could not be determined. ROUTINE: SISIAINS CODE: INS~SISIAPNS reached SHORT DESCRIPTION: The IN1 segment sub-processor was reached. This exception is a place-marker, indicating that the insurance segment (IN1) sub-processor (specifically for BAR messages, but also called from other contexts) was reached. The exception may be useful in tracing processing during the interface configuration phase. ROUTINE: SISIAPNS CODE: Invalid BAR Evnt <EVN> SHORT DESCRIPTION: Could not find event processing code for the given BAR message event. The ADT Filer's BAR message processor accepts only P01 and P05 events. Additional events may be added at a future date. This exception indicates the event type was not currently supported. ROUTINE: SISIABAR CODE: Invalid movement IEN SHORT DESCRIPTION: Discharge failed because bed control movement creation failed. The ADT Filer calls a bed control procedure to create the discharge movement. This procedure failed to create the movement. The reason can only be determined on a case-by-case analysis. ROUTINE: SISIADT1 ROUTINE: SISIADT3 CODE: LAYGO~..PNS reached SHORT DESCRIPTION: Indicates that LAYGO~SISIAPNS was reached. This is a place marker exception, possibly useful in debugging, indicating that the code to create a new File 36 INSURANCE COMPANY entry was reached. ROUTINE: SISIAPNS CODE: Lock request failed SHORT DESCRIPTION: Discharge movement edit failed because lock request failed. Prior to editing the discharge movement, the ADT Filer requests a lock. If this lock request fails, another process is currently editing the movement, or was editing it and failed to release the lock. This exception can occur when a batch of HL7 messages are received and processed concurrently in parallel tasks. If possible, messages should be paced for processing in sequence to avoid various possible data conflicts between messages for the same patient. ROUTINE: SISIADT1 ROUTINE: SISIADT3 CODE: MasterSwitch OFF SHORT DESCRIPTION: The ADT Filer Master Switch has been changed from SUSPEND to OFF. This exception is recorded when the ADT Filer Master Switch value has been changed from SUSPEND to OFF. It is not recorded if the switch is changed from ON to OFF. 151

152 ROUTINE: SISIADT CODE: MasterSwitch ON SHORT DESCRIPTION: The ADT Filer Master Switch has been changed from SUSPEND to ON. This exception is recorded when the ADT Filer Master Switch has been changed from SUSPEND to ON. It is not recorded when the switch has been changed from OFF to ON. ROUTINE: SISIADT CODE: MasterSwitch SUSPEND SHORT DESCRIPTION: Indicates that the ADT Filer Master Switch has been set to SUSPEND mode. This exception is recorded at the point where the first message event to be processed after setting the master switch to SUSPEND would ordinarily be dispatched. The event is instead held until the master switch is reset. ROUTINE: SISIADT CODE: MCAID Update failed SHORT DESCRIPTION: Updating the MEDICAID ELIGIBLE file failed. The Fileman database server api failed to create or update an entry for the patient in File ROUTINE: SISIAINS CODE: MCARE Update failed SHORT DESCRIPTION: Updating the MEDICARE ELIGIBLE file failed. The Fileman database server api failed to create or update an entry for the patient in File ROUTINE: SISIAINS CODE: Missing 42->44 ptr SHORT DESCRIPTION: Admission VISIT failed due to missing WARD LOCATION:HOSPITAL LOCATION pointer. Inpatient admission visit location (ADT-A01 and ADT-A06, for example) is computed from the WARD LOCATION pointer to HOSPTIAL LOCATION. It is not computed directly using the COMPUTE VISIT LOCATION code, or from the default lookup of unit (PV1.3.1) using the HOSPITAL LOCATION file's "C" index. Thus, even though the location may be valid, and may be computable in the way that outpatient visit locations are computable, the location can fail due to a broken link from WARD LOCATION to HOSPITAL LOCATION. To correct this problem edit the WARD LOCATION:HOSPITAL LOCATION to an appropriate value. ROUTINE: SISIADT1 CODE: Missing patient SSN SHORT DESCRIPTION: (Deprecated) Patient SSN not found. Lookup by social security number has been disabled in the context of computing patient IEN (DFN). This exception cannot occur, unless SSN lookup is re-enabled. 152

153 ROUTINE: SISIACCT CODE: Missing patient XID SHORT DESCRIPTION: Patient external ID (PID.2) not found. IGNORE: YES Patient external ID is not required, but may be used in some contexts, such as to indicate a master patient identifier, or some such. This informational exception can generally be ignored, unless the external ID is significant in the particular interface context. ROUTINE: SISIADT1 ROUTINE: SISIADT2 ROUTINE: SISIADT3 ROUTINE: SISIADT4 ROUTINE: SISIADT5 CODE: Missing PID segment SHORT DESCRIPTION: Could not process 'appointment no show' because PID segment not found. The SIU-S26 message did not contain a PID segment. Therefore the 'no show' could not be processed. ROUTINE: SISIADT1 ROUTINE: SISIADT2 ROUTINE: SISIADT3 ROUTINE: SISIADT4 ROUTINE: SISIADT5 ROUTINE: SISIADTM ROUTINE: SISIAS12 ROUTINE: SISIAT12 ROUTINE: SISIAT15 ROUTINE: SISIAT17 ROUTINE: SISIAT26 CODE: Missing PTF record SHORT DESCRIPTION: Stub PTF record for inpatient admission not created or not found. When AUTO-CREATE PTF is enabled in the SISIADT HL7 INTERFACE PARAMETER entry, an inpatient admission also creates a stub PTF record. Note that this function should always be enabled if admissions can be edited or cancelled. (VistA requires the PTF record in order to reference an admission for canceling.) After creating the admission and attempting to create the PTF record, the ADT Filer checks the PTF record. This exception occurs when that check fails. ROUTINE: SISIADT1 CODE: NEW~SISIADTS reached ROUTINE: SISIADTS CODE: No discharge date SHORT DESCRIPTION: Could not process discharge event because PV1.45 does not have valid date/time. Events such as ADT-A03 or ADT-A07 that discharge the patient from inpatient care in VistA require a date/time of discharge in PV1.45. Without this value the discharge movement cannot be created. ROUTINE: SISIADT3 CODE: No dup VISIT created 153

154 SHORT DESCRIPTION: Specified visit parameters would result in a duplicate visit--not created. ADT Filer version 2.0 checks the visit parameters to determine if creating a visit would result in a duplicate entry, i.e. another visit having the same location, date/time, etc. as an existing visit. If the visit would be a duplicate, it is not created. ROUTINE: SISIAUT2 CODE: No movement IEN SHORT DESCRIPTION: Sanity-check failed on movement IEN while processing a cancel event. This exception should not occur, as other pre-check exceptions will likely identify the problem more exactly before this point is reached. When processing a cancel (in VistA delete) inpatient movement, on return from a call to a VistA subroutine, the movement internal entry number was no longer defined. ROUTINE: SISIADTC CODE: NOTASK~SISIADT ROUTINE: SISIADT CODE: OADT~SISIACCT failed SHORT DESCRIPTION: Outpatient admission (visit) date/time not found for current account. The ADT Filer uses a private API to traverse the transaction history for the current (HL7 message) account number to find an outpatient admission date/time (i.e. visit date/time). This exception indicates failure of this API. ROUTINE: SISIACCT CODE: ONE~SISIAGU Bad File SHORT DESCRIPTION: Auxiliary field map failed to process because the identified file was invalid. The VistA File specified in the auxiliary field map entry does not exist (or the specification is otherwise invalid). Therefore, the field map could not be processed. ROUTINE: SISIAGU CODE: ONE~SISIAGU Bad Fld SHORT DESCRIPTION: Auxiliary field map failed to process because the field was invalid. The field specified in the auxiliary field map entry is not a number. This exceptions does not mean that the field does not exist in the file, rather that it is not a valid field number. Note that it is okay to specify a field that does not exist in an auxiliary field map entry, in order to accomplish some other action (e.g. custom transform). ROUTINE: SISIAGU CODE: ONE~SISIAGU Bad IENS SHORT DESCRIPTION: Auxiliary field map failed to process because the IENS was invalid. No IENS was specified in the field map entry. This does not mean that a given IENS failed a structure check, or did not match a real IENS. It means that the IENS is missing. 154

155 ROUTINE: SISIAGU CODE: ONE~SISIAGU reached SHORT DESCRIPTION: Auxiliary field map processor was reached for an entry in File This exception is a place-marker, indicating that the auxiliary field map processor was reached for one entry in File When verbose logging is enabled, each entry in File should have a corresponding informational exception of this type, following completion of event processing. ROUTINE: SISIAGU CODE: OPT VISIT disallowed SHORT DESCRIPTION: Parameter SISI DO NOT CREATE OPT VISIT prevented outpatient VISIT creation. This exception informs when an outpatient VISIT would have been created by the event (subject to other parameter settings) but was not created because the parameter SISI DO NOT CREATE OPT VISIT was valued YES (true). ROUTINE: SISIAUT2 CODE: Opt: Invalid DDT SHORT DESCRIPTION: Outpatient discharge failed because discharge date/time was not found. The outpatient discharge date/time may be found in PV1.45 or EVN.3 or ENV.2, depending on event type and context. If the discharge date time was not found according to rules in effect for the event, then this exception is recorded and the discharge fails. ROUTINE: SISIADTO CODE: Opt: Visit not found SHORT DESCRIPTION: Could not process outpatient discharge because no visit found for the account. An outpatient discharge event could not be processed because no outpatient visit was found in the account transaction history. An outpatient visit may exist for another account, or conceivably could exist for the current account but not be properly referenced in the account transaction history. ROUTINE: SISIADTO CODE: ORD~SISIAGU Bad PROT SHORT DESCRIPTION: Sanity-check failed on existence of protocol ID when processing a field map. This exception should not occur, as the protocol ID has been verified before reaching this point. If it does occur, then the auxiliary field map processing code has been reached improperly, or some sort of process corruption has occurred. ROUTINE: SISIAGU CODE: ORD~SISIAGU Param Er SHORT DESCRIPTION: Environment sanity-check failed on entering the field map processor. This exception should not occur. The elements that fail checking at this point have been verified previously. The exception can only occur if the field map processor is called from an invalid context or some sort of corruption has occurred in the process. ROUTINE: SISIAGU 155

156 CODE: ORD~SISIAGU reached SHORT DESCRIPTION: Auxiliary field map processor was reached. This exception is a place-marker, indicating that the auxiliary field map processor was reached. The indicator is recorded at the point where the auxiliary field map processor will traverse the ORDER index. ROUTINE: SISIAGU CODE: P01: Missing MRN SHORT DESCRIPTION: BAR-P01 (Add patient account) failed because PID.3 did not include MRN-type ID. This event requires that one of the patient internal identifiers in PID.3 specify the identifier type code MRN. If the sender specifies a different literal code for this meaning, then the code should be pre-translated in the engine. ROUTINE: SISIAP01 CODE: P01~SISIAP01 reached SHORT DESCRIPTION: The BAR-P01 event handler was reached. This exception is a place-marker, indicating that the BAR-P01 message event handler was reached. This message handler is currently an implementation-specific extension to the ADT Filer's ADT message processor. ROUTINE: SISIAP01 CODE: P05~SISIAP05 reached SHORT DESCRIPTION: The BAR-P05 event handler was reached. This exception is a place-marker, indicating that the BAR-P05 message event handler was reached. This message handler is currently an implementation-specific extension to the ADT Filer's ADT message processor. ROUTINE: SISIAP05 CODE: Patch URL not found SHORT DESCRIPTION: The parameter SISI ADT FILER PATCH URL does not have a value. The parameter SISI ADT FILER PATCH URL is used by the ADT Filer patch checking option SISIADT PATCH NOTIFICATION. The value of this parameter should be the web page that lists available ADT Filer patches. In August 2010, this page is - ROUTINE: SISIAV23 CODE: Patient died SHORT DESCRIPTION: (Transfer event) Patient has a DATE OF DEATH entry in the PATIENT file. While processing an inpatient transfer event the ADT Filer found that the patient has a DATE OF DEATH recorded in the PATIENT file. The ADT Filer will attempt to process the transfer after recording this informational exception. ROUTINE: SISIADT1 ROUTINE: SISIADT2 CODE: Patient not found SHORT DESCRIPTION: Patient lookup failed in 'update account' event. 156

157 BAR-P05 could not be processed because the referenced patient was not found and the SISI PROCESS BAR-P05 AS P01 is not valued 'YES'. Note that patient lookup uses the account API in this context. ROUTINE: SISIAP05 CODE: PHY fields OK ROUTINE: SISIADT8 CODE: Please install patch SHORT DESCRIPTION: Scheduled option 'Check for ADT Filer patches' found an uninstalled patch. Option SISIADT PATCH NOTIFICATION 'Check for ADT Filer patches' found an available ADT Filer patch that is not recorded as STATUS 'Install Completed' in the INSTALL file. It is generally recommended to install available ADT Filer patches in a timely manner. First read the patch release notes for any special considerations and for general information about the patch. Note that if patch checking is enabled (i.e. this exception) it is recommended to subscribe one or more ALERT USER(s) to this exception for the obvious reason. This exception does NOT pertain to ADT Filer message processing. If it is recorded during or near the time of other exceptions that may pertain to message event processing, it should be considered independent of these and not related in any way to HL7 message event processing. ROUTINE: SISIAV23 CODE: PPHY External ROUTINE: SISIADTS CODE: PPHY VistA ROUTINE: SISIADTS CODE: PPRV: No external ID SHORT DESCRIPTION: No primary provider ID found in PV The ADT Filer version 2 primary provider computation first uses the COMPUTE PRIMARY PROVIDER method specified in File 29320, if that method is valued. If this fails, a default computation, based on PV is used. This exception indicates that the ADT Filer fell through to the default computation and did not find a provider (external) ID in PV ROUTINE: SISIAV2 CODE: PROCESS: Bad IENS SHORT DESCRIPTION: Import failed for a field map due to a problem with IENS. This exception occurs when importing field maps from a host file. It is not an HL7 interface exception. The import failed at the point when the field map was being added (or merged) to File , due to an IENS problem. ROUTINE: SISIAUT1 CODE: PROCESS: Bad TYPE SHORT DESCRIPTION: Import failed because protocol is not an event driver on target system. 157

158 This exception occurs when importing field maps from a host file. It is not an HL7 interface exception. The import failed at the point of checking the protocol referenced against the samenamed protocol on the target system. The protocol does not exist on the target system. ROUTINE: SISIAUT1 CODE: PROCESS: No protocol SHORT DESCRIPTION: Import failed because the protocol does not exist on the target system. This exception occurs when importing field maps from a host file. It is not an HL7 interface exception. The import failed at the point of looking up the protocol referenced in the field map entry on the target system. This lookup failed, meaning the protocol does not exist or is ambiguously named. ROUTINE: SISIAUT1 CODE: PRVNS Update failed SHORT DESCRIPTION: Private insurance or HMO update failed (Fileman returned error). An attempt to update File ( INSURANCE ELIGIBLE) failed. Fileman returned an error on attempting to create a new entry in this file. ROUTINE: SISIAINS CODE: Pt Loc not updated ROUTINE: SISIADTL CODE: Reg: Can't file PPID SHORT DESCRIPTION: Primary patient ID could not be processed when registering a new patient. If a primary patient ID field map entry exists (i.e. referenced as such in the SISIADT HL7 INTERFACE PARAMETER file entry, the ADT Filer processes this entry at the point of new patient registration, not after registration is complete, as with other field map entries. Currently only File 2 is supported for primary patient ID (PPID). Note that filing IDs to the Health Record No. field of file is independent of the file 2 PPID. This exception indicates a failure occurred when processing the File 2 PPID at the point of new patient registration. ROUTINE: SISIADT4 CODE: Reg: Duplicate MRN SHORT DESCRIPTION: Attempt to register a new patient failed because the MRN exists in VistA. The BAR-P01 event attempts to add a patient account for a patient whose MRN matches that of a patient already registered in VistA. Note that it is possible that the patients referred to by the HL7 message and existing in VistA are the same. However, the ADT Filer cannot process in any case, as this would create a duplicate in VistA. ROUTINE: SISIAP01 CODE: Reg: Duplicate SSN SHORT DESCRIPTION: (Deprecated) Attempt to register a new patient with SSN of existing patient. This code has been disabled in the ADT Filer and the exception cannot 158

159 occur unless the code and check is re-enabled. Its purpose was to prevent registering a new patient with the same social security number as an existing patient. However, SSN is not generally used as a patient ID outside the VA, and some senders use a common pseudo-ssn for many patients, rendering this check impractical to use. ROUTINE: SISIADT4 CODE: Reg: Invalid PPID SHORT DESCRIPTION: Primary patient ID field map (pointed-to by File 29320) is invalid. This exception may reflect a dangling pointer. The File entry for PPID does not resolve to a valid primary patient ID field map in File ROUTINE: SISIADT4 CODE: Reg: PPID lock fail SHORT DESCRIPTION: New patient entry failed because lock request failed. Before creating a new patient entry the ADT Filer locks the primary patient ID. If this request fails, probably another concurrent process is attempting to register this patient. Other possibilities exist, but the most likely is that multiple event messages have been received and are being processed concurrently, where more than one of them (e.g. an A04 an A01) are permitted to register a new patient. This can happen when the interface has been shut down and restarted, after which a batch of messages that were awaiting processing are received all at once. Event processing overlaps causing the lock conflict to occur. If the exception reoccurs on an attempt to register the same patient, check the lock table for a dangling lock assoicated with that patient's primary patient ID. The lock node will be of the form: ^XTMP("SISIADT4",<<Patient primary ID>>). When clearing the spurious lock, exercise care to avoid inadvertently clearing another lock belonging to the same process ID. ROUTINE: SISIADT4 CODE: Reg: Recurring Pt. SHORT DESCRIPTION: Implementation-specific check for recurring patient returned true. In the context of new patient registration and implementation-specific check for a recurring patient returned true. ROUTINE: SISIADT4 CODE: Registration aborted SHORT DESCRIPTION: COMPUTE DFN detected possible duplicate. New PATIENT entry was not created. Implementation-specific COMPUTE DFN logic can set the applicationwide variable SISIQUIT indicating NOT to create a new PATIENT entry, even though the COMPUTE DFN logic failed to identify an existing patient. The purpose of this exception is to avoid creating duplicate PATIENT entries, when the COMPUTE DFN logic identifies that the patient referenced in the HL7 message may already exist in VistA, but can not be positively identified. For example, two PATIENT entries may have the same primary patient ID, or the primary patient ID may not exist in VistA, while a secondary 159

160 ID may match one or more existing patients, etc. ROUTINE: SISIADT4 CODE: Registration failed SHORT DESCRIPTION: Patient account was not added. After processing DFN computation failed. The BAR-P01 event processor eventually calls UPDATE^DIE to create a new patient record. Everything seemed in order. However the Fileman API failed to create a new record. Possibly, the target system PATIENT file includes one or more required identifiers that are not known to the ADT Filer. ROUTINE: SISIADT1 ROUTINE: SISIADT2 ROUTINE: SISIADT5 ROUTINE: SISIAP01 CODE: RMBD: Invalid config SHORT DESCRIPTION: Room-bed update failed because ADT Filer is not configured for this update. Possibly the room-bed update code was reached via an inpatient PV1 message in an 'outpatient only' configuration. In any case the room-bed could not be computed, probably due to a missing or invalid ROOM-BED TRANSFORM method in File ROUTINE: SISIADT8 CODE: RPC: <NAME> SHORT DESCRIPTION: Attempt to file data to the VISIT file failed in remote procedure call. The ADT Filer calls a utility in its remote procedure implementing code to file data to the VISIT file, for example when processing an outpatient discharge. This exception indicates that the RPC wrapper returned an error. ROUTINE: SISIADTO CODE: Rtn~XTHC10 not found SHORT DESCRIPTION: A routine used by patch XT*7.3*123 was not found. This exception reflects a double-check on the patch XT*7.3*123 installation. If the patch itself was found, but a routine that is part of the patch was not found, then reinstall patch XT*7.3*123. This patch has no bearing on ADT Filer message event processing, even if it is recorded at or near the same time as HL7 message exceptions. ROUTINE: SISIAV23 CODE: S12: Bad AIL Loc SHORT DESCRIPTION: Make Appointment failed because the AIL.3 location was invalid. The 'make appointment' pre-processor failed to find a valid location resource ID in AIL.3. ROUTINE: SISIAS12 CODE: S12: Bad Appt DT SHORT DESCRIPTION: Make Appointment failed because the AIS.4 appointment date/time was invalid. 160

161 The 'make appointment' pre-processor failed to find a valid appointment date/time in AIS.4. ROUTINE: SISIAS12 CODE: S12: Bad Hosp Loc SHORT DESCRIPTION: Make Appointment failed because the appointment location could not be found. The 'make appointment' pre-processor attempts to compute the location in several ways, finally defaulting to the SISI DEFAULT VISIT LOCATION. Appointment location could not be computed. ROUTINE: SISIAS12 CODE: S12: Bad PT ID SHORT DESCRIPTION: 'Make appointment' failed because patient ID could not be computed. The 'make appointment' pre-processor computes patient ID from the account API. If that fails and the SISI SIU-S12 REGISTER PATIENT parameter is not YES, the current exception occurs. ROUTINE: SISIAS12 CODE: S13: not implemented SHORT DESCRIPTION: Re-scheduling appointment event is not currently implemented. The ADT Filer does not currently process a notification of appointment rescheduling. ROUTINE: SISIASIU CODE: SAVEMSG: No message SHORT DESCRIPTION: Testing utility could not save message (no message found). This is not an HL7 interface exception. It can occur in the context of using a testing / development utility to save the current HL7 message. This feature is enabled by a setting in File 29320, but should not be used, except in the development context. ROUTINE: SISIAUT1 CODE: SAVEMSG: Open failed SHORT DESCRIPTION: Testing utility could not save message because host file open failed. This is not an HL7 interface exception. It can occur in the context of using a testing / development utility to save the current HL7 message. This feature is enabled by a setting in File 29320, but should not be used, except in the development context. ROUTINE: SISIAUT1 CODE: Sched Admit Bad ADT SHORT DESCRIPTION: Scheduled admission failed because admission date/time could not be computed. The ADT Filer attempts to determine the planned admission date/time from PV2.8, and failing that from PV1.44. If neither field has a valid admit date/time, the scheduled admission cannot be processed. ROUTINE: SISIADT5 CODE: Sched Admit failed SHORT DESCRIPTION: Inpatient pre-admit event failed to create entry in File

162 The ADT Filer calls UPDATE^DIE to create a SCHEDULED ADMISSION. This call returns the IEN of the scheduled admission on success. The present exception indicates that UPDATE^DIE failed to return an IEN, and hence the admission was not created. No other information is available at this point. Possibly the reservation date/time was invalid. It would be necessary to study the message and context in depth to determine the cause of failure. ROUTINE: SISIADT5 CODE: Sched No primary SHORT DESCRIPTION: Primary provider could not be computed for a scheduled admission. The ADT Filer attempts to compute the primary provider for a scheduled admission in the same ways as for a specialty transfer. These attempts failed. ROUTINE: SISIADT5 CODE: Sched No ward SHORT DESCRIPTION: Ward location could not be computed for a scheduled admission. The ADT-A05 event handler currently computes WARD using a hard-coded lookup of the "C" index in the WARD LOCATION file (44). This method will likely be generalized by a subsequent ADT Filer patch to use more flexible lookups, based on the WARD TRANSFORM field of the SISIADT HL7 INTERFACE PARAMETER file, etc. ROUTINE: SISIADT5 CODE: SISIQUIT detected SHORT DESCRIPTION: Indicates that a sub-process requested to QUIT (ABORT) A sub-process set the SISIQUIT variable to a TRUE value causing the process to exit at the point of detecting the request. As of patch SISIADT*2.0*14 this exception is generated only in the context of post-events processing, after executing the PREP/SCREEN POST-EVENTS supported API. However, in the future the exception may be recorded in other contexts. ROUTINE: SISIADBA CODE: SPEC: No admission SHORT DESCRIPTION: Specialty transfer movement failed because admission was not found. This exception should not occur. However, in processing a specialty transfer movement a sanity-check on the referenced admission movement failed. The movement IEN exists, but the movement itself does not. Theoretically this is a dangling pointer, but in fact the exception is unlikely to occur. ROUTINE: SISIADTS CODE: SPEC: No ASK SHORT DESCRIPTION: Auto-add treating specialty movement not enabled. ADT Filer cannot ask to create a treating specialty movement, if not automatically enabled. ROUTINE: SISIADTS CODE: SPEC: No attending SHORT DESCRIPTION: Attending physician could not be computed for specialty transfer movement. While processing a specialty transfer movement, the ADT Filer attempted 162

163 to determine the attending provider (physician) by a succession of methods, beginning with the COMPUTE ATTENDING PHYSICIAN code in the SISIADT HL7 INTERFACE PARAMETER file, and falling through to a default lookup based on fields #11, #12, and #13 in the SISIADT HL7 INTERFACE PARAMETER file (PV1.7.1 in the HL7 message). These attempts to compute the attending provider failed. However, the specialty transfer movement will be created (unless prevented by other failures). ROUTINE: SISIADTS CODE: SPEC: No primary SHORT DESCRIPTION: Primary provider could not be computed for specialty transfer movement. >While processing a specialty transfer movement, the ADT Filer attempted to determine the primary provider (physician) by a succession of methods, beginning with the COMPUTE PRIMARY PHYSICIAN code field in the SISIADT HL7 INTERFACE PARAMETER file, and falling through to a default lookup based on fields #11, #12, and #13 in the SISIADT HL7 INTERFACE PARAMETER file (PV in the HL7 message). These attempts to compute the primary provider failed. However, the specialty transfer movement will be created (unless prevented by other failures). ROUTINE: SISIADTS CODE: Undefined event type SHORT DESCRIPTION: ADT Filer cannot process message because event type is not defined. This exception can only occur due to a configuration error. The ADT Filer's main 'processing routine' (i.e., code called by the subscriber protocols) could not identify the message event type. This means that the ADT Filer was called improperly, either by a protocol that is not part of the interface, or by a improperly configured interface protocol. ROUTINE: SISIADT CODE: Upd dup VST for acct SHORT DESCRIPTION: Parameter SISI PROCESS DUP OPV AS UPDATE=YES. Update existing visit for account. The event type would create a new VISIT entry, except that the parameter SISI PROCESS DUP OPV AS UPDATE indicates that only one visit is allowed per account number. Since a visit exists for the account, that visit will be updated. ROUTINE: SISIAV22 CODE: UPDAID: No DFN SHORT DESCRIPTION: Implementation-specific patient ID update failed. This exception should not occur, because the patient IEN has been pre-checked, and if not valid, should have produced a 'Patient not found' exception. The present exception is a sanity-check, in case the code to update alternate ID was reached without DFN validation. This code is in an implementation-specific part of the BAR-P05 event processor, and may be removed in a future revision of the ADT Filer interface. ROUTINE: SISIAP05 CODE: Update DDT mvmt type SHORT DESCRIPTION: Update of discharge date/time failed because movement is the wrong type. This is a sanity-check exception that should not occur in normal 163

164 processing because other checks would have triggered a fatal exit before reaching this check of the discharge movement transaction type. If this exception occurs one would suspect corruption of the account number transaction movement pointer. ROUTINE: SISIADT8 CODE: Update DDT no DSCHRG SHORT DESCRIPTION: Update of discharge movement failed because discharge was not found for account. An update of discharge date/time could not be applied because no discharge movement was found for the account. ROUTINE: SISIADT8 CODE: Update DDT no MVMT SHORT DESCRIPTION: Update of discharge movement failed. The ADT Filer was attempting to update the date/time of a previous discharge for the account, but was unable to determine the movement to be updated. ROUTINE: SISIADT8 CODE: UPDATE: No DFN SHORT DESCRIPTION: Patient identifier update failed due to invalid or missing DFN. This exception should not occur, because the patient IEN has been pre-checked, and if not valid, should have produced a 'Patient not found' exception. The present exception is a sanity-check, in case the code to update SEX, DOB, SSN, etc. was reached without DFN validation. This code is in an implementation-specific part of the BAR-P01/P05 event handlers. ROUTINE: SISIAP05 CODE: UPDATE~ Reg. Failure SHORT DESCRIPTION: A new PATIENT registration failed in the UPDATE~DIE call. A new patient registration should not fail in the final stage of processing, via the call to UPDATE^DIE. However, under special conditions, such as contradictory parameter settings, failure can occur. For example, if the ADT Filer is set to ignore FOIA required identifiers, and the PATIENT file DD has not been modified in a corresponding way, the call to UPDATE^DIE can fail, due to insufficient data. Another example, is if the parameter SISI DISALLOW FILING SSN is valued YES but the #.09 field remains a required identifier, registration can fail, unless the application supplies an SSN or pseudo-ssn via some other mechanism. ROUTINE: SISIADT4 CODE: UPDATE~ Reg. Failure SHORT DESCRIPTION: A new PATIENT registration failed in the UPDATE~DIE call. A new patient registration should not fail in the final stage of processing, via the call to UPDATE^DIE. However, under special conditions, such as contradictory parameter settings, failure can occur. For example, if the ADT Filer is set to ignore FOIA required identifiers, and the PATIENT file DD has not been modified in a corresponding way, the call to UPDATE^DIE can fail, due to 164

165 insufficient data. Another example, is if the parameter SISI DISALLOW FILING SSN is valued YES but the #.09 field remains a required identifier, registration can fail, unless the application supplies an SSN or pseudo-ssn via some other mechanism. ROUTINE: SISIADT4 CODE: UPDATE~ Reg. Failure SHORT DESCRIPTION: A new PATIENT registration failed in the UPDATE~DIE call. A new patient registration should not fail in the final stage of processing, via the call to UPDATE^DIE. However, under special conditions, such as contradictory parameter settings, failure can occur. For example, if the ADT Filer is set to ignore FOIA required identifiers, and the PATIENT file DD has not been modified in a corresponding way, the call to UPDATE^DIE can fail, due to insufficient data. Another example, is if the parameter SISI DISALLOW FILING SSN is valued YES but the #.09 field remains a required identifier, registration can fail, unless the application supplies an SSN or pseudo-ssn via some other mechanism. ROUTINE: SISIADT4 CODE: UPDATE~..P05 reached SHORT DESCRIPTION: BAR-P05 demographic update handler (generic update) was reached. This exception is a place-marker, indicating that the update demographic information handler, originally part of the BAR-P05 event handler and now a generic update processor, was reached. ROUTINE: SISIAP05 CODE: UPRQID: No DFN SHORT DESCRIPTION: Required identifiers update failed due to invalid or missing DFN (patient IDN). This exception should not occur, because the patient IEN has been pre-checked, and if not valid, should have produced a 'Patient not found' exception. The present exception is a sanity-check, in case the code to update required identifiers was reached without DFN validation. ROUTINE: SISIAP05 CODE: V31 PTF not enabled ROUTINE: SISIADTS CODE: WARD precheck failed SHORT DESCRIPTION: Pre-check of ward location failed. Movement was not created. If the parameter SISI INP ADM LOC PRE-CHECK is set to YES, the ADT Filer will pre-check the WARD location, based on message data (and the WARD TRANSFORM field of File 29320). If this check fails, the movement will not be created. If the parameter SISI INP ADM LOC PRE-CHECK is set to NO, or not valued, the ADT Filer will not pre-check WARD location, prior to creating the movement and this specific exception cannot occur. ROUTINE: SISIADT1 165

166 CODE: WhileASIH Invalid DT SHORT DESCRIPTION: Discharge from LTC while ASIH failed due to missing (actual) discharge date. At attempt to discharge a patient from long term care while absent sick in hospital failed due to an invalid or missing discharge date. The event processor would normally edit the +30-day discharge date to the actual date, as specified in the message PV1.45. However, the latter date/time cannot be determined. Therefore the discharge movement edit failed. ROUTINE: SISIASIH CODE: WhileASIH No +30 MDA SHORT DESCRIPTION: Discharge from LTC while ASIH failed due to missing +30 day discharge date. At attempt to discharge a patient from long term care while absent sick in hospital failed due to an invalid or missing +30-day discharge date. The event processor would normally edit the +30-day discharge from its future date to the actual date, as specified in the message PV1.45. However, the future discharge date/time cannot be determined. Therefore the discharge movement edit failed. ROUTINE: SISIASIH CODE: WhileASIH No Dsch DT SHORT DESCRIPTION: Discharge from LTC while ASIH failed due to missing PV1.45 date/time. At attempt to discharge a patient from long term care while absent sick in hospital failed due to an invalid or missing PV1.45 date/time in the discharge message. The event processor would normally edit the +30-day discharge from its future date to the actual date, as specified in the message PV1.45. However, the latter cannot be found. Therefore the future discharge movement edit failed. ROUTINE: SISIASIH CODE: XFER: Never admitted SHORT DESCRIPTION: Inpatient transfer failed because no prior admission was found. The ADT Filer uses the "APTT1" index of the PATIENT MOVEMENT file to pre-check whether the patient was ever admitted to the medical center. If no admission is found, then there can be no corresponding admission for the transfer, and the transfer event fails. ROUTINE: SISIADT2 CODE: XT*7.3*123 not found SHORT DESCRIPTION: Kernel toolkit patch XT*7.3*123 was not found. Option SISIADT PATCH NOTIFICATION 'Check for ADT Filer patches' requires Kernel toolkit patch XT*7.3*123 in order to check for available patches. If the XT patch is not installed on the system, then the SISIADT PATCH NOTIFICATION option cannot function and should be unscheduled (removed from the scheduled tasks). This exception has no bearing on ADT Filer HL7 message event processing, even if it is recorded at or near the same time as HL7 message exceptions. It simply means that a patch used by the ADT Filer patch checking option is not available, and therefore the latter cannot check for patches and should not be scheduled. 166

167 ROUTINE: SISIAV23 CODE: ~VSIT Error <IEN> SHORT DESCRIPTION: Attempt to create a VISIT file entry failed. The ADT Filer calls a wrapper API, which in turn calls ^VSIT to create an outpatient or inpatient admission VISIT. The ^VSIT API itself returned an error. This could be a configuration issue, such as VISIT TRACKING PARAMETERS file specifications, or it could be a message-specific or context-specific issue. Additional study is needed to determine the cause of failure. ROUTINE: SISIAUT2 167

168 ADT Filer Version 2 Installation Checklist See appropriate sections of this Installation and Setup document for detailed information about the steps outlined below. 1. Check patch level of KIDS routine ^XPDIA1 >W $T(KEYF1^XPDIA1) KEYF1 ;SECURITY KEY file pre DO NOT PROCEED unless routine XPDIA1 includes the above KEYF1 tag. 2. Load / install ADT Filer v 2.0 KID, upgrade KID, and V2.0 patches up to current patch level. 2a. If DSS vxvista-based environment, load patient registration routine. For open-source vxvista, routine is VFDOSREG.RO. 2b. If not vxvista-based and not filing MRN to PATIENT/IHS HRN, or if filing to HRN and another location, create PPID field map entry. 3. Create user FILER,ADT or equivalent service user (no logon access). 4. Configure sending facility name (MSH.4) as IDENTIFIER of appropriate INSTITUTION entry, CODING SYSTEM = ADT FILER. >S XUMF=1 D Q^DI Select INSTITUTION NAME: <APPROPRIATE VALUE HERE> (Branch to field 9999) Select CODING SYSTEM: ADT FILER CODING SYSTEM ID: <SFN> If vxvista-based environment, create IMPLEMENTATION-SPECIFIC API entry for REGISTER PATIENT. Select SISIADT IMPLEMENTATION-SPECIFIC API NAME: REGISTER PATIENT Are you adding 'REGISTER PATIENT' as a new SISIADT IMPLEMENTATION- SPECIFIC API (the 1ST)? No// Y (Yes) XECUTE: D MRN^VFDOSREG NOTES: 1>Generic vxvista single-id patient registration Configure SISIADT HL7 INTERFACE PARAMETER entry 1 (details elsewhere in this guide). 7. Configure selected Kernel PARAMETERS (XPAR MENU). 8. Configure ADT Filer event-driver protocols for the appropriate SENDING APPLICATION name and HL7 VERSION ID. Note that in RPMS environment, this field is called SERVER APPLICATION. 9. Add ITEMs to SISIA MOVEMENT EVENTS (or to other ADT Filer extended action protocols), as appropriate. 10. Create translation table entries, as needed. 11. Create auxiliary field map entries, as needed. 168

169 12. Examine VistA HL7 infrastructure components to be sure that they are functional and enabled, e.g. HL7 Site Parameters, Link Manager multilistener logical link, and IN-filer. 13. If installing to GT.M, shutdown and restart Taskman sub-managers and HL7 in-filers. 169

170 Summary of HL7 to VistA Data Dictionary Mappings (In-Line Processing Only) Segment Seq.Com DD File DD Field Notes MSH Conditional Conditional EVN Transfer and EVN.2 is not valued Transfer and EVN.6 is not valued or parameter to override EVN.6 = YES Transfer or class change. PID 2 3 Implementation-specific patient ID Implementation-specific patient ID Translation required DINUM ed Translation required Translation required Supported API Translation required DINUM ed PD Translation required 170

171 PV1 2 Conditional branch PV1.2 + PV Admission and transfer movements only, excluding ASIH. Requires File entry. Implementation-specific branch Requires translation Implementation-specific branch Implementation-specific Implementation-specific Requires translation PV Implementation-specific branch User-defined appointment API NK1 2 2 NOK, K2, Emer. Contact or Emp. 3 depending on translated NK Conditional branch 13 Not filed 34 Not filed 171

172 IN Parameter-based LAYGO Note that additional HL7 data elements may be filed through field maps or postevent protocols. 172

173 Troubleshooting and Problem Solving Definition: For the purpose of the following discussion, a well-defined problem is an unexpected result or outcome of processing a received HL7 message. For example, if an HL7 message is expected to file or change some VistA data, and the data are not filed or modified as expected, then a problem has been identified. If a message causes some change to data that was not expected, then a problem has been identified. Here are some examples: Problem: ADT-A01 message 1234 failed to create an (expected) admission visit. Not problem: Visits are not being created in VistA. Problem: ADT-A06 message 5678 failed to cancel pre-existing outpatient orders. Not problem: The ADT Filer is not cancelling orders. Problem: ADT-A04 message ABCD produced a Registration Failed exception and the patient is not in VistA. Not problem: Registration isn t working! Background: It is important to understand the main flow of HL7 message processing, from the sending system to ADT Filer event processing, in order to identify the level at which a problem has occurred. Generally, the levels are: 1. Sender (System that transmits original ADT message to VistA) 2. [Optional] Interface Engine 3. VistA HL7 Infrastructure, HL* routines, Files 772, 773, and etc. 4. ADT Filer processing routine (runs in in-filer thread). 5. ADT Filer event handler (runs as scheduled task in background). The following diagram, reproduced from the Overview section of this guide, illustrates levels 1 through

174 When the ADT Filer s processing routine receives the message it performs preliminary steps in the in-filer thread. Important steps, parsing the message and creating or updating the ACCOUNT NUMBER entry, are illustrated in the following diagram. While it is possible to process the event in the same thread for debugging purposes (labeled foreground in the above diagram), in practice event processing is scheduled through VistA Taskman to be completed in the background. 174

175 How to tell whether a particular processing level was reached: If the message was received in VistA (level 3), an entry for the message will exist in the HL7 MESSAGE ADMINISTRATION file (773), provided the DAYS TO KEEP parameter of the VistA HL7 Site Parameter has been suitably valued. If the message was received by the ADT Filer s processing routine, the STATUS of the File 773 entry for the message will be SUCCESSFULLY COMPLETED. If also the ADT Filer s LOG STATUS is set to VERY VERBOSE or higher, the exception EN~SISIADT0(<MSG>,<EVN>) will have been recorded. If the processing level does not progress from level 3 (VistA) to level 4 (ADT Filer), the File 773 entry should include an explanatory error status. Also, if MSH.15 is not NE, the VistA HL7 system would have returned a negative acknowledgement on the message channel, in this case. When configuring a new implementation, it is helpful to set the log status to VERBOSE or VERY VERBOSE. For production implementation it is recommended to set or reset the log status to NORMAL. In VERY VERBOSE mode when level 5 (event processing) is reached, additional exceptions will be recorded, beginning with Dequeue <EVN>~SISIADT. Note that Taskman must be running for events to dequeue. If some contrary finding is observed in relation to the above, it is prudent to check the Kernel error record using ^XTER to see if an error occurred that could have disrupted the normal flow. Investigating problems: In the following it will be assumed that processing has reached level 5 and a well-defined problem has occurred. Principles: This discussion will address practical aspects of investigating ADT Filer problems. However, first it may be helpful to enumerate a few principles that apply to problem solving in general, and equally apply to examining problems that arise in the ADT Filer interface context. 1. Formulate a clear, precise and unambiguous description of the problem. 2. Assess the importance, priority, and scope of the problem. 3. Ascertain whether the problem is reproducible or occurs intermittently under conditions that are not yet fully understood. 4. Establish the context of the problem. Identify concomitant events, dependencies, or connections. 5. Acquire relevant supporting data. 6. Analyze. Apply tools specific to the problem (to be described for ADT Filer problems). 7. Generate and test hypotheses. Rule out false solutions. Do not discard the obvious. 8. Avoid extraneous effort, such as duplication, perseveration, etc. 175

176 9. When a solution has been deduced, verify it by testing not only in the original context, but in related contexts as well. When problems are reported by VistA users, they are sometimes not stated precisely, and in a few cases might be stated in a misleading way. It is important to probe what the person reporting the problem means. Ask questions to clarify exactly what was expected, and what actually occurred, when it occurred (or failed), and any other potentially relevant facts surrounding the problem. Is the problem a patient safety issue? Does it have any identified or potential secondary effects? Is it causing additional work? These types of question should be asked, to assess the importance and scope of the issue. Can the problem be reproduced from the information at hand? Eventually, to understand the problem fully it may be necessary to reproduce it. Does sufficient information exist at present to reproduce the problem in a test environment? What additional information would be needed to reach this stage? Practical Steps: This discussion pertains to ADT Filer-specific problems, i.e. those that arise in the context of the ADT Filer interface. The best approach for any particular problem is difficult to specify in advance although one might strive to build a repertoire of investigative actions that have been productive for previous problems. In regard to collecting evidence 1. Always check: a. Kernel error trap (routine ^XTER) b. ADT Filer Exceptions Log (option Print ADT Filer Exceptions ) c. ACCOUNT NUMBER file TRANSACTION history. 2. Depending on the event, etc: a. If registration or patient demographics, examine the PATIENT file b. If inpatient, examine the PATIENT MOVEMENT file c. If outpatient, examine the VISIT file To begin investigating any problem it is necessary to have a toe hold on the problem. This means there must be some means to determine which patient or which admission or which visit, etc., is in question. The toe hold can be a patient account number, or a patient ID (MRN) or an HL7 message control ID, or an admission date/time or other information that is sufficient to enable sure identification of the subject. If the only available datum is the HL7 message control ID, then it is essential that the message still exists in VistA. HL7 messages are automatically purged after the DAYS TO KEEP parameter value of the HL7 Site Parameter. It is not enough to have a copy of the message in the interface engine (if there is one). It should be possible to examine the message as it was received in VistA, in order to rule out any possible misunderstanding about message field translations, and so forth. 176

177 From the message itself one can generally read the account number (PID.18), and using that value, examine the ACCOUNT NUMBER file entry for the event (transaction) as well as other events preceding and following the one in question these surrounding events may well be important in understanding what happened. (See the ADT Filer s Chronological Transactions for Patient option.) Patients generally have multiple accounts and it may be difficult to identify the most relevant one for a given problem, when starting from the patient MRN. However, it is also possible to identify an account from a related admission movement or visit, as the ACCOUNT NUMBER file is indexed by both movement and visit. It is generally helpful to make notes, Control ID, account #, patient MRN (or DFN), movement or visit date/time, etc. Among other data, the ACCOUNT NUMBER : TRANSACTION CONTOL ID multiple includes the date/time that the ADT Filer processed the event. This is useful to establish bounds on the part of the exceptions log that should be examined. For example, ACCOUNT ID: TRANSACTION CONTROL ID: 5732 PATIENT: YEATS,WILLIAM BUTLER VISIT: JUN 01, 2010@08:00 EVENT TYPE: A01 PATIENT: YEATS,WILLIAM BUTLER DATE/TIME: JUL 29, 2010@08:31:39 MOVEMENT: JUN 01, 2010@08:00 CLASS: INPATIENT To display exceptions related to processing HL7 message 5732, one could specify a start time of 8:30 and end time of 8:32, for example. Select OPTION NAME: Print ADT Filer Exceptions START WITH DATE@TIME: FIRST// 7/29@8:30 (JUL 29, 2010@08:30:00) GO TO DATE@TIME: LAST// 7/29@8:32 (JUL 29, 2010@08:32:00) DEVICE: ;;9999 It is especially good to narrow the exceptions range, when recording in verbose or very verbose log status mode. If an exception is found that appears to be relevant to the problem, further information about the exception can be found in the SISIADT EXCEPTION TYPE file ( ) or in this document. Some exception types that would seem to indicate something is wrong are in fact uninformative in common contexts, for example JUL 29, :31:41 Missing patient XID 5732 This exception refers to the fact that the HL7 message does not contain an external patient ID in field PID.2. However, most ADT Filer implementations do not use 177

178 this field. 20 With practice one learns to recognize exceptions that do not belong in the processing context under examination. Let us suppose that some data element that should be present is missing from the VistA record, for example, the attending physician for an admission. The next step of the investigation would be to display the HL7 message, as it was received in VistA. Select OPTION NAME: Show HL7 message Message control ID: PV1 I TW^102^ ^^ T0001^WELBY^MARCUS^ T0001^WELBY^MARCUS^ 0^^^ 12 1 T0002^PIERCE^HAWKEYE^ D P 01 P The attending doctor is field PV1.7 and the message includes that data element. In verbose mode, the exception record would have specific information relating to the failure, but even if it did not, the process of investigating the cause of this failure would be straightforward. First, was the file attending physician part of the event processed? If it was (no errors, subsequent parts were processed, etc.), then something must be wrong in resolving the provider ID. What does the ADT Filer s main parameter file have for resolving the attending provider? Check the value of field #19.2 COMPUTE ATTENDING PHYSICIAN in the parameter entry (File 29320, entry 1). If this field is not valued, then next check the following fields: 11 INBOUND PROVIDER VISTA FILE 12 INBOUND PROVIDER VISTA FIELD# 13 INBOUND PROVIDER VISTA XREF These fields describe a secondary method for computing providers, when the provider type (primary physician or attending physician) does not have a separately defined compute method. What if these fields too are not valued? Then the ADT Filer s internal default is used. This default looks up the provider code value from PV1.7.1 using the PS2 index on File 200. In any case, whatever method is present and defined must have failed in this case. Check the data! Does the provider have an entry in the field (or fields) specified by the compute process? If the answer to this question is yes, then test the compute code in isolation. If this test fails, then identify the cause of failure and how it can be remedied. 20 Some senders do use this field for an MPI value. Other senders simply duplicate an internal ID from PID.3 in this field. 178

179 The above example is artificial, and proceeds along an unlikely path, in which compute code for resolving the attending physician has not been properly specified. However, in general, the method of analysis would apply to any ADT Filer problem. Only the paths differ, depending on the specific data elements that are involved. It is not possible to edit the content of a received HL7 message and then to reprocess it. Or, more precisely it is strongly advised not to do this. However, if the message itself is good, and a correction has been made to a VistA data element, say an ADT Filer parameter field, such that the message could now process correctly, and if the timing of the message remains valid (meaning that in relation other messages that have processed subsequently, this one would not create an invalid sequence if reprocessed), then the message may be reprocessed using the convenience option SISIADT REPROCESS HL7 MESSAGE. The Reprocess ADT Filer HL7 Message option should be used sparingly, and only when it has been determined safe and appropriate to do so. HL7 ADT Filer Overall Menu (SISIADT OVERALL) Utility options [SISIADT Reprocess ADT Filer HL7 UTILITIES MENU] Message [SISIADT REPROCESS HL7 MESSAGE] Clearing the Task Sync Flag and Resource Device: If the parameter SISI SINGLE-THREAD EVENT TASKS is enabled (value=yes), and an ADT Filer event processing task has failed to complete normally, it will be necessary to clear the Task Sync Flag and the ADT Filer s Resource Device, in order to re-enable (restart) ADT Filer event processing. The above-described situation can arise if a MUMPS error occured during event processing or post-event processing. It can also arise if the system was halted during event processing. In this situation, the File 773 entry for the message or messages indicates the status SUCCESSFULLY COMPLETED. Event processing has been successfully tasked. However, event processing tasks are accumulating in the TASKS file, and are not being handed to the ADT Filer event s entry point DQ^SISIADT for processing. To clear both the Task Sync Flag and Resource Device use the following two options in the order indicated: 179

180 1. Select Taskman Management Utilities Option: SYNC flag file control Select TASK SYNC FLAG NAME: SIS ADT FILER SYNC~SIS ADT FILER SIS ADT FILER SYNC~SIS ADT FILER Select one of the following: Z S Q ZAP START NEXT QUIT What to do with this one:: ZAP ZAPPED 2. Select Device Management Option: Clear one Resource Select RESOURCE NAME: SIS ADT FILER Select SLOTS IN USE SLOT IN USE: 1 180

181 Using Bed Control Options: Under some circumstances it may be necessary to run a VistA Bed Control option manually in order to correct an erroneous patient movement sequence. VistA Bed Control consists of the options DG ADMIT PATIENT, DG TRANSFER PATIENT, and DG DISCHARGE PATIENT. When taking this exceptional step, one should be aware that the ADT Filer uses the TRANSACTION CONTROL ID multiple of the ACCOUNT NUMBER file as its primary source of information about a patient account. Creating or deleting a patient movement through VistA Bed Control does not automatically update the ADT Filer s record of that specific inpatient episode of care. In other words, the TRANSACTION CONTROL ID multiple of the ACCOUNT NUMBER file will not automatically refer to a movement created manually. To assist in maintaining a synchronous record in the TRANSACTION CONTROL ID multiple, after using one of the bed control options to create a patient movement, use option Point ACCOUNT NUMBER to movement/visit to update the corresponding ACCOUNT NUMBER record Utility options [SISIADT Reprocess ADT Filer HL7 UTILITIES MENU] Message [SISIADT REPROCESS HL7 MESSAGE] Point ACCOUNT NUMBER to movement/visit [SISIADT POINT ACCOUNT NUMBER] While this procedure is not assured to avert subsequent ADT Filer movement sequence type errors, in most cases it improves the chance that subsequent inpatient events for the same account will be handled correctly. For additional suggestions regarding troubleshooting ADT Filer problems, see the power point presentation Revised-ADTFiler-Overview-October2009.ppt. 181

182 Exporting / Importing Configuration Settings ADT Filer configuration settings may be exported to a host file or imported from a host file using the export/import options of the System Definition Menu. HL7 ADT Filer Overall Menu (SISIADT OVERALL) System Definition Menu [SISIADT SYSTEM DEFINITION MENU] Export / Display Configuration Settings [SISIADT EXPORT CONFIGURATION] Import and File Configuration Settings [SISIADT IMPORT CONFIGURATION] These options are most useful when working with two nearly identical environments, such as the test and production accounts of a single site. However, the Import option may also be used to bootstrap the configuration at a new implementation site. And, since the host file that is generated by the Export option is a text file, similar in structure to an.ini file, it is possible to edit this file, replacing saved values with values relevant to the target (import) environment. Configuration settings that are saved by the Export option include the following groups: Attribution User Auxiliary Field Map definitions ADT Filer HL7 Interface Parameter settings ADT Filer Kernel PARAMETERS values File SISIADT CONSTANTS entries Implementation-specific API definitions HL7 Sending Applications referenced in ADT Filer protocols Modified ADT Filer Event Protocols ADT Filer Extended Action Protocol ITEM entries ADT Filer coding system entries in the INSTITUTION file In addition to the time-savings benefit, configuration files may be used to store a snapshot of a configuration for reference, prior to making configuration changes. They may also be used to reproduce a specific production configuration in a laboratory setting for testing some anomalous occurrence. The Import option should be used with care. For example, when importing settings to a different domain it is necessary first to edit the configuration file, replacing references to the export domain with the appropriate target domain name. If this is not done, ADT Filer Kernel parameters will not be filed, or will be filed to the exporting domain, if it exists on the target system. 182

183 Testing a New Interface After installing the ADT Filer and performing basic configuration steps, as described in the first part of this document, the next step is to test the interface by sending selected HL7 messages, preferably identical in structure to those generated by the intended sender, but with test data in place of real data. If the same environment (database) will be used for production later, then it is important to anticipate the form and range of real patient identifiers, MRNs, account numbers, etc., and make sure that the test values cannot possibly collide with future real patient values. The following are suggested guidelines for the overall testing process. 1. Test one event at a time. 2. Start with patient registration and demographics. 3. Test outpatient and inpatient events separately. 4. Correct and retest at each step, before proceeding. The most complex part of testing deals with verifying that patient movement events, inpatient admissions, transfers and discharges in VistA properly reflect the patient s status in the sending system. It is suggested to test these inpatient events in the following order: 1. Admission (e.g. ADT-A01) 2. Discharge (A03) 3. Cancel Discharge (A13) 4. Inter-ward transfer (A02) 5. Cancel transfer (A12) 6. Cancel admission (A11 7. More complex events and sequences, including for example, A06, A21/22, multiple transfers, and to/from ASIH (if applicable). Patients in VistA are either receiving care as patient class O [outpatients] or patient class I [inpatients], or are not receiving care. The ADT Filer interface does not in general support other patient classes. The PV1 segment is not relevant to registering patients who are not receiving care (or not scheduled to receive care, i.e. scheduled visit or admission). For patients who are receiving care, the PV1 segment conveys crucial information, such as the admission date, patient assigned location, and so forth. Most importantly, it identifies the patient class in field PV1.2. This field should contain either and I or and O for inpatient or outpatient, respectively. 183

184 It is useful to acquire familiarity with VistA terminology, in order to avoid misunderstanding. The term admission in VistA refers to an inpatient admission. While an outpatient admission is a visit in VistA. Other common terms have somewhat different meanings between different hospital systems and the VistA EMR. VistA is a patient-centric system. It does not natively respect patient account number. Account number associations are established and maintained by the ADT Filer interface, as an add on feature. The following are general suggestions for troubleshooting new implementations, as well as interface problems in general. 1. State the problem precisely. Break the problem into sub-problems, if possible. Investigate each part separately. 2. Examine all file entries associated with the problem event, until all are fully understood. For example, if the problem deals with an inpatient location, examine both File 2 and File 405 location fields, as a discrepancy could exist. 3. Use VistA options, for example Patient Inquiry, as well as Fileman. 4. Be aware that the patient s current VistA status may reflect activity in more than one account. 184

185 Uninstalling the ADT Filer Programmer access to the VistA environment where the ADT Filer is installed is required to uninstall the application. In addition, the user who uninstalls the interface must possess the SISIADT UNINSTALL security key. To uninstall the ADT Filer, from the programmer prompt enter DO SURE^SISIAUNS You will have one chance to opt out, after which, the ADT Filer will be uninstalled from the environment. The uninstall process will remove components that were installed in the virgin build, and components that were added in patches. In other words, the uninstall process will remove all ADT Filer components, such as options, routines, templates, etc., except those that are explicitly protected from removal, such as the uninstall routine itself, and files or sub-files that contain patient data, for example, the ACCOUNT NUMBER file. During the uninstall process, various messages will be displayed to indicate removal or preservation of specific components. To prevent the program from displaying these messages set the variable SISQUIET=1, prior to running the routine. 185

186 186