Previous Page TOC Index Next Page

10.2 PLACER APPLICATION REQUESTS AND TRIGGER EVENTS

Placer request and filler response transactions are the messages and trigger events used between placer applications and filler applications. The placer application initiates transactions using the SRM message, requesting that the filler application modify its schedule(s) with the given trigger event and information. The filler application responds to these requests, using the SRR message, to either grant or deny the requests from the placer application.

When initiating a request, the placer application will generate and send an SRM message containing all of the information necessary to communicate the desired action to the filler application. All required segments and fields (both explicitly required and conditionally required) should be provided to the filler application, as defined in this chapter. When the filler application receives the transaction, it acknowledges it with the appropriate accept acknowledgment using an ACK message (assuming that the enhanced acknowledgment mode is in use). After processing the request at the application level, the filler acknowledges the transaction with the appropriate application acknowledgment in an SRM message (again 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 in the context of this chapter, an application accept from the filler means that the request was processed and accepted by the filler. An application error from the filler means that the request was processed and denied. An application reject from the filler 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 filler system is down, or there was an internal error). When appropriate, an SRM message with an application accept acknowledgment will contain further information on the request that was processed.

There are no unsolicited messages initiated from a filler application defined in this set of trigger events. Those messages and trigger events are defined below, in Section 10.3, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED."

All of the trigger events associated with placer request and filler response transactions use a common message definition, that follows:

SRM     Schedule Request Message     Chapter
MSH     Message Header        2
ARQ     Appointment Request Information    10
[ APR ]    Appointment Preferences      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
      [ APR ]  Appointment Preferences      10
      [ { NTE } ]  Notes and Comments       2
     }
  ]
  [ { AIG   Appointment Information - General Resource  10
      [ APR ]  Appointment Preferences      10
      [ { NTE } ]  Notes and Comments       2
     }
  ]
  [ { AIL   Appointment Information - Location Resource 10
      [ APR ]  Appointment Preferences      10
      [ { NTE } ]  Notes and Comments       2
     }
  ]
  [ { AIP   Appointment Information - Personnel Resource 10
      [ APR ]  Appointment Preferences      10
      [ { NTE } ]  Notes and Comments       2
    }
  ]
}
SRR     Scheduled Request Response    Chapter
MSH     Message Header        2
MSA     Message Acknowledgment      2
[ ERR ]    Error Information        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
      [ { 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
      }
    ]
  }
]

Note that in the abstract message definitions for both the SRM and SRR, the patient information segments (segments PID through DG1) are both optional as a group, and repeating as a group. The optionality allows for transactions that relate to a patient, and for those that do not. The ability to repeat the patient information allows for those transactions in which one activity must be scheduled for multiple patients (e.g., for family or group therapy).

In contrast, a transaction may specify no more than (and no less than) one activity. Note that neither the ARQ segment (in the SRM message) nor the SCH segment (in the SRR message) are allowed to repeat, and that they are required. Neither the optionality nor the ability to repeat patient information allows a transaction to specify more than one activity.

The trigger events that use this message definition are listed below.

Previous Page TOC Index Next Page