10.3 FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED
Unsolicited transactions from filler applications are the messages and trigger events used between filler applications and auxiliary applications. Transactions are initiated by the filler application, using the SIU message to notify auxiliary applications of modifications in a filler applications schedule(s). The auxiliary application responds to these notifications, using the ACK message, either to acknowledge receipt of the transaction, or to signal that an interfacing error of some kind has occurred.
This set of trigger events is also used to notify applications fulfilling the placer application role of changes in the filler applications schedule(s), if the application is configured to accept these messages and trigger events as an auxiliary application would. As the discussion of application roles has indicated above, any one application can have more than one application role. If it is important that the application acting in the placer application role in your messaging environment be notified of unsolicited changes to a filler applications schedule(s), then it must also support the role of an auxiliary application.
When initiating a notification transaction, the filler application will generate and send an SIU message containing all of the information necessary to communicate the desired information to the auxiliary application. All required segments and fields (both explicitly required and conditionally required) should be provided by the filler application, as defined in this chapter. When the auxiliary application receives the transaction, it acknowledges with the appropriate accept acknowledgment using an ACK message (assuming that the enhanced acknowledgment mode is in use). After processing the notification at the application level, the auxiliary application acknowledges the transaction with the appropriate application acknowledgment in an ACK message (assuming that an application acknowledgment was requested under the enhanced acknowledgment mode, or that the original acknowledgment mode is in use). Applying the explanations of the various application acknowledgment codes (detailed in Chapter 2) in the context of this chapter, an application accept from the auxiliary application means that the notification was processed and accepted. An application error from the auxiliary application means that the auxiliary application was unable to process the notification at the application level. An application reject from the auxiliary application means that the request was not, and could not, be processed due to one or more reasons unrelated to its content (for example: it fails the basic application protocol validation, the system is down, or there was an internal error).
All of the trigger events associated with unsolicited transactions from filler applications use a common message definition, that follows:
SIU Schedule Information Unsolicited Chapter
MSH Message Header 2
SCH Schedule Activity Information 10
[ { NTE } ] Notes and Comments 2
[ { PID Patient Identification 3
[ PV1 ] Patient Visit 3
[ PV2 ] Patient Visit-Additional Information 3
[ { OBX } ] Observation Segment 4
[ { DG1 } ] Diagnosis Information 6
}
]
{ RGS Resource Group Segment 10
[ { AIS Appointment Information - Service 10
[ { NTE } ] Notes and Comments 2
}
]
[ { AIG Appointment Information - General Resource 10
[ { NTE } ] Notes and Comments 2
}
]
[ { AIL Appointment Information - Location Resource 10
[ { NTE } ] Notes and Comments 2
}
]
[ { AIP Appointment Information - Personnel Resource 10
[ { NTE } ] Notes and Comments 2
}
]
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error Information 2
The trigger events that use this message definition are listed below.