Chapter Chair/Editor: |
John
Lynch, CHREF |
Editor: |
David
C. Means |
This
chapter defines abstract messages for the purpose of communicating various
events related to the scheduling of appointments for services or for the use of
resources. There are three basic types of messages defined in this transaction
set: request transactions and their responses, query transactions
and their responses, and unsolicited transactions and their responses.
Request transactions communicate requests for the scheduling of appointments
for services or for the use of resources. These transactions occur between
placer (requesting) applications and filler (processing)
applications. The query and unsolicited transaction sets provide for the
exchange of scheduling information between systems. The exchange of this
information is achieved either actively or passively. The active gathering of
scheduling information is performed by issuing query transactions to a filler
application from a querying application. The passive gathering of this
information is performed by accepting unsolicited transactions issued by a
filler application.
This chapter describes various roles under which applications might operate.
The roles discussed in this chapter illustrate the underlying model used to
develop this specification. They do not imply the need for a particular
application model or method of implementation.
This chapter defines the transactions at the seventh level, that is, the
abstract message. Various schemes are used to generate the actual characters
that comprise the messages according to the communication environment. The HL7
Encoding Rules will be used where there is not a complete Presentation Layer.
This is described in Chapter 1, "Relationship to Other Protocols." The
examples included in this chapter were constructed using the HL7 Encoding Rules.
The
goal of this specification is to facilitate the communication of scheduling
requests and information between applications. Such communication involves
three main subjects: schedules, appointments, and services and
resources. Schedules control the occurrence of certain services and the
use of particular resources. They consist of a set of open, booked and blocked
slots for one particular service or resource. Open slots are periods of
time on a schedule during which a service may occur, and/or a resource is
available for use. Booked slots are periods of time on a schedule that
have already been reserved. Appointments occupy sets of one or more
booked slots on a schedule. They describe the nature of the service and/or the
use of the resource, the person or persons responsible for the appointment's
booking, and other information relevant to the booking and execution of an
appointment. Blocked slots on a schedule are periods of time during
which a service or resource is unavailable for reasons other than booked
appointments (for example, a piece of equipment might be unavailable for
maintenance reasons).
In the context of this chapter, services and resources are those things that
are controlled by schedules. Services are real-world events, such as
clinic appointments, the performance of which is controlled by a schedule.
Often, these kinds of activities relate to the care of a patient. In other
words, appointments for services often schedule a service for one or more
patients. Resources are tangible items whose use is controlled by a
schedule. These "items" are often people, locations, or things low in supply
but high in demand.
A
schedule controls the dates and times available for the performance of a
service and/or the use of a resource. One schedule applies to one service or
resource, since each service or resource can be reserved independently of the
others. (If two or more services, people, locations, or things cannot be
reserved independently of one another, they are considered to be one activity
or resource.) A schedule consists of slots of time during which the controlled
service or resource is potentially available for performance or use. Slots are
categorized as open, booked, or blocked. An open slot on a schedule indicates
that the service or resource is available for performance or use during that
period of time. A booked slot indicates that the service or resource is not
available during the time period, because an appointment has been scheduled. A
blocked slot indicates that a service or resource is unavailable for reasons
other than a scheduled appointment.
The real-world, non-automated analog of the schedule described above is a
standard appointment book. These books are generally organized with rows of
time slots, during which a service or resource is available. The following
figure illustrates an excerpt from such an appointment book.
Date: |
May 17, 1994 |
|||||||
Room A |
Room B |
Room C |
Room D | |||||
8:00 am |
Pat: B Smith |
|||||||
:15 |
Dr.: Peters |
Closed for |
||||||
:30 |
Physical |
Pat: N Drew |
remodeling |
|||||
:45 |
Exam |
Dr.: Collins |
||||||
9:00 am |
Pat: J Adams |
Allergy |
Pat: A Jones | |||||
:15 |
Dr.: Anders |
Scratch Test |
Dr.: Peters | |||||
:30 |
Follow-up |
Each
cell in the figure above represents a slot on a schedule. Different shading
patterns represent booked and blocked slots. Information identifying the
appointments scheduled in booked slots is written in the appointment book.
Similarly, explanations are written into the book when resources are blocked.
Those cells with no shading and comments represent open slots.
As in the figure above, appointment books commonly contain more than one
column. This format allows the scheduling of more than one resource or
activity within the same book. This chapter defines a schedule as an entity
controlling the availability of only one resource or service for a given period
of time. Given that definition, each column in the above excerpt from the
appointment book represents a separate schedule for a separate resource.
Services
and resources are the "what" in any communication of scheduling transactions,
that is, they are things--either tangible or intangible--that the transaction
is attempting to affect or describe. The services and resources that are
controlled by schedules are typically in high demand. In any case, their use
or performance is managed through the process of reserving blocks of time.
Services are typically activities that occur in a certain location, where
specific people and equipment exist to carry out the activity. The activity
must be scheduled prior to its occurrence. The schedule that controls the
activity may not be the same schedule that controls the location, people, and
equipment. For example, patient visits to a clinic are typically controlled
through scheduling. Patients receive an appointment at the clinic, and at the
appointed time are seen by a member of the clinic staff. From the point of
view of the person or application requesting the appointment for the patient,
the "thing" being scheduled is a service (e.g., a doctor's consult, an X-ray,
etc.). The assignment of an exam room and (in this example) a physician, nurse
practitioner, or other staff member is incidental to the actual appointment.
Resources are tangible things that must be reserved prior to their use.
Examples might include MRI equipment, portable X-ray machines, or rooms.
People are also tangible resources that are often scheduled. Typically these
people controlled by schedules have special roles, perform special activities,
and are in high demand.
The following are the primary attributes that describe a resource:
* A unique identification code
The unique identification code for a
service or resource describes a specific instance of that service or resource.
For tangible resources, this may be a serial number, a location, an employee
number, or another unique designation. For services, the identification of a
slot on the schedule is usually sufficient for unique identification.
* A code describing the type of class of service or resource
This code
describes a type or class of service, or resource groups like services or
resources together. For services, this is typically a universal service ID
similar to the field used in the OBR segment defined in the Order Entry chapter
(Chapter 4). This Universal Service ID uniquely identifies clinical services
performed in a healthcare provider organization.
For tangible resources,
this code may be a model number, a staff classification (such as physician,
nurse, physical therapist, etc.), or a kind of room. This kind of information
can be used to request a resource from a pool, where a specific instance of the
resource scheduled is unknown and unimportant (as long as it is of the
specified type or class).
* A name or text description of the resource
The name or text
description of the resource provides a human-readable identification of the
service or resource.
When a resource is associated with an appointment, or is requested for an
appointment, the following attributes describe the relationship (or requested
relationship):
* The start date and time the service or resource is required for the
appointment
The start date and time the service or resource is required
for the appointment describes the point at which the service or resource should
be made available to the activity. In this specification, this is represented
as a positive or negative time offset from the start date and time of the
appointment.
* The duration for which the service or resource is needed for the
appointment
The duration for which the service or resource is required
for the appointment describes how long the service or resource is needed to
complete the appointment. By adding the duration to the start date and time,
the end date and time can be calculated for the required resource or service
within the activity.
Other attributes further describe services and resources. These attributes are
communicated, as necessary, in transactions between applications.
Appointments
are instances of the performance of a service or the use of a resource. They
describe the "why," the "who," and the "when" in any communication of
scheduling transactions. These appointments occupy one or more slots on a
service or resource schedule, causing those slots to become unavailable or
"booked." Appointments can describe scheduled activities related to patients
in a healthcare setting, or they can describe scheduled activities wholly
unrelated to patients.
In its simplest form, an appointment consists of one service or resource
reserved for a period of time, for a specific reason. More complex activities
involve multiple services or resources, or parent-child relationships to other
appointments.
The primary attributes for the appointment which describes a scheduled activity
include the following:
* a unique placer appointment identification code
The placer appointment
identification code uniquely describes an instance of an appointment. It is
used in communications between placer and filler applications to identify a
particular appointment (or a request for an appointment booking) on the placer
application. Except in special circumstances, the code is assigned by the
placer application upon making an initial scheduling request. This concept is
similar in practice to the placer order number found in Chapter 4, Order
Entry.
* a unique filler appointment identification code
The filler appointment
identification code uniquely describes an instance of an appointment. It is
the filler application's counter-part to the placer appointment identification
code. It is used in communications between placer and filler applications to
identify a particular appointment (or request for an appointment booking) on
the filler application. Except under special circumstances, it is assigned by
the filler application when an appointment (or a request for an appointment
booking) is created by the filler application. This concept is similar in
practice to the filler order number found in Chapter 4, Order Entry.
* an appointment start date and time
The appointment start date and time
describe the beginning of the appointment. In request transactions, the
appointment start date and time are expressed as a preference or list of
preferences. The filler application uses this expression of preference to book
the appointment. Once an appointment has been booked, the start date and time
are expressed in the actual scheduled start date and time.
* an appointment duration
The appointment duration describes how long
the appointment will last, and consequently, the end date and time of the
appointment.
Supporting information about service and resource activities includes the
following:
* reason codes to describe the reason that the service is occurring or the
resource is being used;
* patient information to describe for whom the appointment is taking place,
whether the appointment or scheduled activity is for, or related to, a
patient;
* requestor information to describe the person responsible for initiating and
executing the appointment;
* location information to describe where the appointment is scheduled to
occur.
* Other attributes further describe appointments. These attributes are
communicated as necessary in transactions between applications.
Parent
appointments are those appointments that embody one or more child appointments.
For example, a request for a repeating appointment results in a logical parent
(the original scheduled appointment request), and one or more children (each
individual occurrence of the appointment). This specification provides no
information about how individual applications store or handle parent and child
appointments, but it does provide a mechanism for identifying individual
occurrences (children) within transactions.
Either the placing application or the filling application can specify child
appointments--and in one of two ways. If each individual child appointment is
assigned a separate and unique Placer Appointment ID and/or Filler Appointment
ID, then that unique identifier may be used in transactions to specify an
individual child. If, however, neither the placer nor filler application
assigns a unique identifier separately, an occurrence number can be used. Both
the ARQ and SCH segments allow for an occurrence number, which is a unique
serial number assigned to each child within a parent appointment.
In
this specification, there are four roles that an application can assume: a
filler application role, a placer application role, a querying application
role, and an auxiliary application role. These application roles define the
interaction that an application will have with other applications in the
messaging environment. In many environments, any one application may take on
more than one application role.
In this specification, the definition of application roles is not intended to
define or limit the functionality of specific products developed by vendors of
such applications. Instead, this information is provided to help define the
model used to develop this specification, and to provide an unambiguous way for
applications to communicate with each other.
The
filler application role in the scheduling model is very similar to the filler
application concept presented in Chapter 4, Order Entry. A filler application,
in the scheduling model, is one that "owns" one or more schedules for one or
more services or resources. In other words, a filler application exerts
control over a certain set of services or resources and the schedules that
define the availability of those services or resources. Because of this
control, no other application has the ability to reserve, or to otherwise
modify, the schedules controlled by a particular filler application.
Other applications can, on the other hand, make requests to modify the
schedules owned by the filler application. The filler application either
fulfills or denies requests to book slots, or to otherwise modify the schedules
for the services and resources over which it exerts control.
Finally, the filler application also provides information about scheduled
activities to other applications. The reasons that an application may be
interested in receiving such information are varied. An application may have
previously requested bookings or modifications on the schedule, or may simply
be interested in the information for its own reporting or statistical purposes.
There are two methods whereby filler applications disseminate this information:
by issuing unsolicited information messages, or by responding to queries.
The analog of a filler application in a non-automated environment might be an
appointment book and the person in charge of maintaining that book. The
appointment book describes when the resources are available and when they are
booked. This appointment book is the only official record of this information,
and controls the availability of the resources to any user. The person in
charge of this appointment book takes requests to book the resources, and
decides whether to accept or reject the requests based on the information
recorded in the appointment book. Anyone needing information from the
appointment book either consults the book directly, or contacts the person in
charge of the book.
The
placer application role in the scheduling model is also very similar to its
counterpart in the Order Entry chapter. A placer application requests the
booking, modification, cancellation, etc., of a scheduled activity for a
service or resource. Because it cannot exert any control over the schedule for
that resource, it must send its requests to modify the schedule to the filler
application. In requesting that these appointments be booked or modified in
some way, the placer application is asking the filler application to exert its
control over the schedule on the placer application's behalf.
The analog of a placer application in a non-automated environment might be any
person needing a particular resource or appointment for a service. A person
needing to book an appointment would contact the person in charge of the
appointment book for that resource or service, and request a reservation.
Often, there is negotiation between the person requesting the reservation or
appointment and the person who maintains the appointment book. The requesting
person will indicate requirements and preferences, and the person controlling
the appointment book will indicate whether the request can be fulfilled as
specified.
A
querying application neither exerts control over, nor requests changes to a
schedule. Rather than accepting unsolicited information about schedules, as
does an auxiliary application, the querying application actively solicits this
information using a query mechanism. It will, in general, be driven by a
person wanting information about schedules, and may be part of an application
filling the placer application role as defined in this chapter. The
information that the querying application receives is valid only at the exact
time that the query results are generated by the filler application. Changes
made to the schedule after the query results have been returned are not
communicated to the querying application until it issues another query
transaction.
The analog of a querying application in a non-automated environment might be
any person needing information about a specific portion of a schedule. For
example, a facilities manager may need to know whether a specific room has been
scheduled during a specific period of time. This person might ask the person
controlling the appointment book about the specific room and period of time in
question.
Often, a placer application will also act as a querying application. The
ability to send queries and receive lists of open slots is built in to some
implementations of placer applications. These placer applications use this
information to select open slots for subsequent booking requests. The current
specification does not imply that placer applications should or should not also
be able to fulfill the role of a querying application. Instead, the model
defines these roles separately. Applications that support this functionality
may take advantage of this application role in the model. Applications that do
not support the querying application role are not limited in their support of
the placer application role.
Like
querying applications, an auxiliary application neither exerts control over,
nor requests changes to a schedule. It, too, is only concerned with gathering
information about a particular schedule. It is considered an "interested
third-party," in that it is interested in any changes to a particular schedule,
but has no interest in changing it or controlling it in any way. An auxiliary
application passively collects information by receiving unsolicited updates
from a filler application.
The analog of an auxiliary application in a non-automated environment might be
any person receiving reports containing schedule information. For example, a
facilities manager may need to know what rooms are booked for activity during
specific periods of time. This person might ask the person controlling the
appointment book for a periodic listing of activity, which may be something as
simple as copies of pages from the appointment book.
Often, a placer application will also act as an auxiliary application. A
placer application may have the capacity to store information about the
scheduled activity that it requested. In such cases, the placer application is
also an "interested" application in that it wishes to receive any messages
describing changes to the content or status of the scheduled activity it
initiated.
In
a messaging environment, these four application roles communicate using
specific types of messages and trigger events. The following figure
illustrates the relationships between these application roles in a messaging
environment:
This chapter defines several trigger events used to communicate scheduling information between applications. In addition, it also defines, suggests, or allows for several statuses that scheduled activities may hold, several reasons a scheduled activity may occur, and several types of scheduled activities. The distinction between these four concepts is important for understanding the information in this chapter.
The trigger events for this chapter are defined in Section 10.2, "PLACER APPLICATION REQUESTS AND TRIGGER EVENTS, " 10.3, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED," and 10.4, "QUERY TRANSACTIONS AND TRIGGER EVENTS." Traditionally, trigger events define the transition of some entity from one state to another.[1] Typical trigger events may be listed as follows: new, cancel, modify, discontinue, reschedule, and delete.
The
status of a scheduled activity describes where that activity is in its life
cycle. A status differs from a trigger event in an important way: a status
describes the current condition of an entity, whereas a trigger event is
generated to "move" the entity from one state to another. All status fields in
this chapter are defined with respect to the application acting in the role of
a filler, unless otherwise (and specifically) indicated. Therefore, a status
in a scheduling interface transaction is only truly meaningful if the
transaction was generated by the application assigning or maintaining that
status.
Typical statuses for a schedule transaction might include the following:
pending, wait-listed, confirmed, canceled, discontinued, deleted, started,
completed, overbooked (booked for a resource along with another conflicting
appointment), blocked, etc.
This
chapter defines two kinds of reasons used with transactions. The first is an
appointment reason that indicates why the appointment is being booked - and
ultimately why the activity is going to occur. The second is an event reason
that describes why a particular trigger event has been generated. Reasons tend
to be static, whereas statuses tend to change. In contrast, trigger events
describe an action to be performed.
Appointment reasons tend to be relatively static for the life of the scheduled
activity. Typical examples of appointment reasons include the following:
routine, walk-in, check-up, follow-up, emergency, etc.
Event reasons are static as well, but only for the life of a particular trigger
event. Typical examples of event reasons include the following: no-show (e.g.,
when an appointment is canceled), at patient request, at caregiver request, etc.
Rather than describing why an appointment has been scheduled - as the appointment reason does - the appointment type describes the kind of appointment recorded in the schedule. This information tends to be administrative in nature. Typical appointment types might include: normal, tentative (or "penciled in"), STAT, etc.
A schedule request or appointment should not be confused, in any way, with orders for services, or for patient referrals. The trigger events and messages defined in this chapter are meant to operate within the realm of scheduling activities, and not to imply that any other trigger event or real-world event has or should occur. It should not be construed from this chapter that any schedule request transaction can be used instead of an order transaction, in which a service or other activity must be specifically ordered. In such cases, a specific order transaction should occur (either electronically or otherwise). If subsequent scheduling transactions are then required to carry out the order, the trigger events and messages defined in this chapter may be used.
An appointment represents a booked slot or group of slots on a schedule, relating to one or more services or resources. Two examples might include a patient visit scheduled at a clinic, and a reservation for a piece of equipment.
An auxiliary application neither exerts control over, nor requests changes to a schedule. It is only concerned with gathering information about a particular schedule. It can be considered an "interested third-party," in that it is interested in any changes to a particular schedule, but has no interest in changing it or controlling it in any way. It may gather information passively or actively. An auxiliary application passively collects information by receiving unsolicited updates from a filler application.
An indication that a slot or a set of slots is unavailable for reasons other than booking an appointment.
The act of reserving a slot or set of slots on a schedule for a service or resource.
A child appointment is an appointment subordinate to another appointment (called a parent appointment). For example, a single instance of an appointment in a group of recurring appointments is a child to the group. Child appointments can themselves be parent appointments. For example, if a battery of appointments is scheduled, then the atomic units of the battery are children to the battery request. If the battery is scheduled as a repeating appointment, then each instance of the battery of appointments (parent to each of the atomic units) is a child to the original repeating request.
The filler application role in the scheduling model is very similar to the filler application concept presented in Chapter 4, Order Entry. A filler application, in the scheduling model, is one that "owns" one or more schedules for one or more services or resources. It fulfills requests to book slots for the services or resources over which it exerts control. It also notifies other applications of activity related to appointments, such as new bookings, modifications, cancellations, etc.
A
parent appointment is an appointment that consists of one or more subordinate
appointments (called child appointments). A parent appointment is used to
relate or group multiple appointments together in various ways. Examples of
kinds of parent scheduled activities include, but are not limited to, the
following.
* Recurring (repeating) appointments. For example, a physical therapy
appointment may be scheduled every Tuesday at 4:00 PM for three months.
* Batteries of appointments. For example, an activity consisting of an
appointment with Radiology, an appointment with a specialist, and an
appointment with a primary care physician might be scheduled.
* Complex appointments. For example, recurring batteries of appointments, or
batteries of battery appointments.
Parent appointments can themselves be children to other appointments.
The role of the placer application in the scheduling model is also very similar to its counterpart in the Order Entry chapter. A placer application must request the booking, modification, cancellation, etc., of an appointment for a service or resource because it cannot exert any control over that service or resource on the schedule. In requesting that these appointments be booked or modified in some way, the placer application is asking the filler application to exert its control over the schedule on the placer application's behalf.
A querying application neither exerts control over nor requests changes to a schedule. Rather than accepting unsolicited information about schedules, as does an auxiliary application, the querying application actively solicits this information using a query mechanism. It will be driven by a person wanting information about schedules, and may be part of an application filling the placer application role as defined in this chapter. The information that the querying application receives is valid only at the exact time that the query results are generated by the filler application. Changes made to the schedule after the query results have been returned are not communicated to the querying application until it issues another query transaction.
A resource is any person, place or thing that must be reserved prior to its use.
A schedule is the sum of all of the slots related to a service or resource.
A service is any activity that must be scheduled prior to its performance.
A slot is one unit on a schedule. A slot represents the smallest unit of time or quantity that a service or resource may be booked. Depending on the nature of the service or resource, there may be more than one defined slot at a given instant of time. For example, if a service is an open group therapy session with twelve available seats, then there are twelve slots for the given block of time.
This
specification contains three functional groupings of trigger events and message
definitions. The trigger events within each of the three functional groupings
share the same or similar message definitions. For clarity, message
definitions shared by multiple trigger events are presented only once.
The first functional grouping of trigger events and message definitions
describes placer request transactions. This grouping defines the
trigger events and message definitions for transactions from applications
acting in a placer application role, and also defines the related filler
application response messages. These messages are described in Section 10.2,
"PLACER APPLICATION REQUESTS AND TRIGGER EVENTS."
The second functional grouping describes trigger events and message definitions
for unsolicited transactions from applications acting in the filler
application role. This grouping describes the unsolicited messages originating
from an application fulfilling the filler role, and the response messages sent
back by applications fulfilling the auxiliary role. These messages are
described in Section 10.3, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS
UNSOLICITED."
The final grouping describes query transactions from applications acting
in the querying application role, and also defines the related filler
application messages used to respond to these queries. These messages are
described in section 10.4, "QUERY TRANSACTIONS AND TRIGGER EVENTS."
The notation used to describe the sequence, optionality, and repetition of
segments is described in Chapter 2, "Format for defining abstract messages."
This chapter uses the "Action code/unique identifier" mode for updating via repeating segments. For more information on updating via repeating segments, please see Section 2.23.4, "Modes for updating via repeating segments," in Chapter 2. The definition of the "Action code/unique identifier" update mode can be found in Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition."
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^S01-S11 |
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 Info |
3 |
[ { OBX } ] |
Observation/Result |
4 |
[ { DG1 } ] |
Diagnosis |
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^S01-S11 |
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 Info |
3 |
[ { DG1 } ] |
Diagnosis |
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.
A placer application sends a transaction with this trigger event to a filler application to request that a new appointment be booked. If it is successful, the filler application returns an application acknowledgment (if requested under the enhanced acknowledgment mode, or if the original acknowledgment mode is in use). The acknowledgment may optionally contain an SCH segment and related detail segments describing the actual appointment that was booked.
A
placer application uses this trigger event to request that an existing
appointment be rescheduled. The new Requested Start Date and Time, Appointment
Duration, Repeating Interval, Repeating Interval Duration, and/or Priority are
provided in the ARQ segment, along with the existing placer and filler
identification numbers. If it is successful, an application acknowledgment is
returned, optionally containing an SCH segment and related detail segments
describing the new information for the rescheduled appointment.
This transaction should not be used to reschedule an appointment that has begun
but has not been completed. In such cases, and only if it is logical to do so,
the appointment should be discontinued and a new schedule request should be
submitted. Likewise, this transaction should not be used to reschedule a
parent appointment, in which one or more children have begun or have already
occurred. Again, the parent appointment should be discontinued, and a new
schedule request should be made. This procedure removes any ambiguity between
applications that may arise with an attempt to modify an appointment that is in
progress.
This message transmits a request for modification of an existing appointment to a filler application. This trigger event is used to request the modification of information on an existing appointment, outside of the need to reschedule, cancel, discontinue or delete the appointment, or to add, modify, cancel, discontinue, or delete services and/or resources on the appointment. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the new information for the modified appointment.
The
request appointment cancellation trigger event is sent by the placer
application to the filler application to request that an existing appointment
be canceled. A cancel event is used to stop a valid appointment from
occurring. For example, if a patient scheduled for an exam cancels his/her
appointment, then a request to cancel the appointment is sent. If it is
successful, an application acknowledgment is returned, optionally containing an
SCH segment and related detail segments describing the canceled appointment.
This trigger event can be used to cancel a parent appointment, in which none of
the children of the appointment have either begun or have been completed. Any
child appointments that exist on the filler and placer applications should be
considered canceled. If one or more child appointments have begun or have been
completed, then this trigger event should not be used. Instead, the S05
(request appointment discontinuation) event should be used.
The request appointment discontinuation is sent by the placer application to the filler application to request that an appointment in progress be stopped, or that the remaining occurrences of a parent appointment not occur as scheduled. If none of the child appointments of a parent appointment have occurred, then a cancel trigger event should be sent instead. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the discontinued appointment.
A
request appointment deletion is sent by the placer application to the filler
application to request that an appointment that had been entered in error be
removed from the system. A delete trigger event should only be used when an
appointment has been erroneously requested, and must be removed from the
schedule so that it does not affect any statistical processing. A delete
trigger event differs from a cancel trigger event in that a delete acts to
remove an error, whereas a cancel acts to prevent a valid request from
occurring. This trigger event should not be used for any appointment that has
already begun, or has already been completed. Likewise, it should not be used
on any parent appointment if any child appointments have either begun or been
completed. If it is successful, an application acknowledgment is returned,
optionally containing an SCH segment and related detail segments describing the
deleted appointment.
The delete trigger event should be implemented with careful forethought, as it
typically has different effects and repercussions in various applications. In
some applications, a delete event cannot be undone. This means that if a
delete transaction was sent erroneously, recovery will be difficult or
impossible. In other applications, a delete transaction will not result in the
physical deletion of the record(s), but will set a status or a flag. In these
cases, the filler and/or placer appointment identifiers (the numbers or codes
that uniquely identify the scheduled appointment or request to the placer and
filler applications) probably cannot be reused. Since these applications
maintain a record of deleted appointments, the reuse of an identifier will
likely cause a conflict in the applications' processing of transactions.
The request addition of service/resource is triggered by the placer application to request that a new service or resource be added to an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.
The
request modification of service/resource is triggered on the placer application
to request that information pertaining to an existing service or resource be
changed for an existing appointment. Services and resources are represented by
the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction.
This trigger event should only be used for appointments that have not been
completed, or for parent appointments whose children have not been completed.
If it is successful, an application acknowledgment is returned, optionally
containing an SCH segment and related detail segments describing the modified
appointment.
This trigger event should not be used when an existing resource or service must
be replaced or rescheduled for an existing appointment. The following fields
on the indicated segments should not be changed by this trigger event: the
first three fields of the AIS, the first four fields of the AIG, the first four
fields of the AIL, and the first four fields of the AIP. Instead, use two
trigger events to accomplish the replacement or rescheduling of a service or
resource: S09 (request cancellation of service/resource on appointment), as
well as S07 (request addition of service/resource on appointment).
This trigger event requests that a service or resource be removed from an existing scheduled appointment that has not yet begun. A cancel event is used to stop a valid service or resource from participating in the appointment. For example, if a portable X-ray machine scheduled for an exam is no longer needed, then the placer application requests that the resource be canceled on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.
A request discontinuation of service/resource is sent by the placer application to the filler application when the remaining occurrences of a recurring appointment no longer require a particular service or resource. In other words, this trigger event is sent to request that the performance of a service or resource in a recurring appointment that has already begun be stopped. If the first appointment in a set of recurring appointments has not yet occurred, then a cancel trigger event should be sent instead. This trigger event should only be used on appointments that have not been completed, or on parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.
A request deletion of service/resource is sent by the placer application to the filler application to request that a scheduled appointment requiring a service or resource entered in error be removed from the system. A delete trigger event should only be used when a service or resource has been erroneously attached to an appointment, and must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from occurring. This trigger event should only be used on appointments that have not been completed, or on parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.
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 application's 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 application's 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
application's 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^S12-S24, S26 |
Schedule Information Unsolicited |
Chapter |
MSH |
Message Header |
2 |
SCH |
Schedule Activity Information |
10 |
[ { NTE } ] |
Notes and Comments |
2 |
[ { PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[ PV1 ] |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info |
3 |
[ { OBX } ] |
Observation/Result |
4 |
[ { DG1 } ] |
Diagnosis |
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^S12-S24, S26 |
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.
This message is sent from a filler application to notify other applications that a new appointment has been booked. The information provided in the SCH segment and the other detail segments as appropriate describe the appointment that has been booked by the filler application.
This
message is sent from a filler application to notify other applications that an
existing appointment has been rescheduled. The information in the SCH segment
and the other detail segments as appropriate describe the new date(s) and
time(s) to which the previously booked appointment has been moved.
Additionally, it describes the unchanged information in the previously booked
appointment.
This transaction should not be used to reschedule an appointment that has begun
but has not been completed. In such cases, and only if it logical to do so,
the appointment should be discontinued and a new schedule request should be
submitted. Likewise, this transaction should not be used to reschedule a
parent appointment, in which one or more children have begun or have already
taken place. Again, the parent appointment should be discontinued, and a new
schedule request should be made. This procedure removes any ambiguity between
applications that may arise with an attempt to modify an appointment that is in
progress.
This message notifies other applications that an existing appointment has been modified on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.
A
notification of appointment cancellation is sent by the filler application to
other applications when an existing appointment has been canceled. A cancel
event is used to stop a valid appointment from taking place. For example, if a
patient scheduled for an exam cancels his/her appointment, then the appointment
is canceled on the filler application.
This trigger event can be used to cancel a parent appointment, in which none of
the children of the appointment have either begun or been completed. Any child
appointments that exist on the filler and placer applications should be
considered canceled. If one or more child appointments have begun or have been
completed, then this trigger event should not be used. Instead, the S16
(notification of appointment discontinuation) event should be used.
A notification of appointment discontinuation is sent by the filler application to notify other applications that an appointment in progress has been stopped, or that the remaining occurrences of a parent appointment will not occur. If none of the child appointments of a parent appointment have taken place, then a cancel trigger event should be sent instead.
A
notification of appointment deletion is sent by the filler application to other
applications when an appointment that had been entered in error has been
removed from the system. A delete trigger event should only be used when an
appointment has been erroneously scheduled. It must be removed from the
schedule so that it does not affect any statistical processing. A delete
trigger event differs from a cancel trigger event in that a delete acts to
remove an error, whereas a cancel acts to prevent a valid request from
occurring. This trigger event should not be used for any appointment that has
already begun, or that has already been completed. Likewise, it should not be
used for any parent appointment if any child appointments have either begun or
been completed.
The delete trigger event should be implemented with careful forethought, as it
typically has different effects and repercussions in various applications. In
some applications, a delete event cannot be undone. This means that if a
delete transaction was sent erroneously, recovery will be difficult or
impossible. In other applications, a delete transaction will not result in the
physical deletion of the record(s), but will set a status or a flag. In these
cases, the filler and/or placer appointment identifiers (the numbers or codes
that uniquely identify the scheduled appointment or request to the placer and
filler applications) probably cannot be reused. Since these applications
maintain a record of deleted appointments, the reuse of an identifier will
likely cause a conflict in the applications' processing of transactions.
The notification of addition of service/resource is triggered on the filler application when a new service or resource has been added to an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.
The
notification of modification of service/resource is triggered on the filler
application when the information pertaining to an existing service or resource
has been changed for an existing appointment. Services and resources are
represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling
interface transaction. This trigger event should only be used for appointments
that have not been completed, or for parent appointments whose children have
not been completed.
This trigger event should not be used when an existing resource or service has
been replaced in relation to an existing appointment. Instead, use two other
trigger events: S20 (notification of cancellation of service/ resource on
appointment), as well as S18 (notification of addition of service/resource on
appointment).
This trigger event notifies other applications that a service or resource has been removed from an existing scheduled appointment that has not yet begun. A cancel event is used to stop a valid service or resource from participating in the appointment. For example, if a portable X-ray machine scheduled for an exam is no longer needed, then the resource is canceled on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.
A notification of discontinuation of service/resource is sent by the filler application to other applications when the remaining children of a parent appointment no longer require a particular service or resource. In other words, this trigger event is sent to discontinue the performance of a service or resource in a parent appointment that has already begun. If the first appointment in a set of recurring appointments has not yet taken place, then a cancel trigger event should be sent instead. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.
A notification of deletion of service/resource is sent by the filler application to other applications when a scheduled appointment requiring a service or resource entered in error has been removed from the system. A delete trigger event should only be used in those circumstances when a service or resource has been erroneously attached to an appointment, and must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from taking place.
A notification of blocked schedule time slots is sent by the filler application to other applications when a schedule has had one or more time slots blocked and made unavailable for reasons other than the scheduling of an appointment. For example, if an exam room is unavailable for several hours because of maintenance needs or contamination, a user may block off those several hours on the exam room's schedule. Similarly, if a physician is unavailable because he or she has taken vacation time, his or her schedule may be blocked off for the duration of the vacation. When these types of conditions exist, the filler application may use this transaction to notify other applications that the resources controlled by schedules are unavailable.
A
notification of blocked schedule time slots is sent by the filler application
to other applications when a schedule has one or more time slots open up
("un-blocked") and become available for use. Typically, the blocked period of
time on a schedule is simply allowed to expire, because the blocked amount of
time is generally used for non-appointment activities. This transaction can be
used either to discontinue the blocked status on the schedule, or to reverse a
previous block made in error. For the purposes of this transaction,
discontinuing a block currently in progress (the blocked period has started,
but not yet completed) and canceling a blocked period in the future are not
significantly different. Therefore, a separate discontinue block transaction
is not necessary. If this transaction is received prior to the inception of a
blocked period, then the entire block period is simply canceled according to
the data provided in the transaction. If the transaction is received after the
blocked period has begun, but prior to the end of the blocked period, then the
blocked period is discontinued according to the data provided in the
transactions. Applications may decide how to handle transactions that attempt
to open a blocked period that has both started and ended in the past; however,
these transactions can generally be ignored.
For example, if an exam room has been blocked for several hours because of
maintenance activities or contamination, and if the work has been completed
ahead of schedule, a user may open those several hours on the exam room's
schedule. When such a situation occurs, the filler application may use this
transaction to notify other applications that the room is available.
A
notification that a patient did not show up for an appointment. For example,
if a patient was scheduled for a clinic visit, and never arrived for that
appointment, this trigger event can be used to set a status on the appointment
record for statistical purposes, as well as to free resources assigned to the
appointment (or any other application level actions that must be taken in the
event a patient does not appear for an appointment).
Patient Administration events defined in Chapter 3 can be used to indicate that
a patient has arrived for an appointment, e.g., A01 (admit/visit notification),
A04 (register a patient), A05 (pre-admit a patient), or A10 (patient arriving -
tracking) as possible examples. Similarly, Patient Administration transactions
can be used to identify the end of an appointment, e.g., A03 (discharge/end
visit) or A09 (patient departing - tracking) as possible examples.
Query
transactions are the messages and trigger events used between querying
applications and filler applications. In Version 2.3 of the Standard, there
are several types of queries available. Original mode display-oriented and
record-oriented queries are compatible with the queries defined in previous
versions of the Standard. New enhanced mode queries include an Embedded Query
Language (EQQ), a Virtual Table Query (VQQ), a Stored Procedure Request (SPQ),
and an Event Replay Query. Original mode display-oriented queries now have an
Enhanced Display Response (EDR) available in Version 2.3. Descriptions and
definitions of these query types are found in Chapter 2, Section 2.16, "Query
Trigger Events and Message Definitions."
As the discussion of application roles has indicated above, any one application
can have more than one application role. If it is important that applications
in your messaging environment that fulfill either the placer or auxiliary
application roles be able to query information actively from a filler
application's schedule(s), then they must also support the role of a querying
application.
Original
mode display-oriented queries are defined in Chapter 2, Sections 2.17,
"Original Mode Queries," and 2.18, "Original Mode Deferred Access." Querying
applications use the QRY message to initiate a query. Specifying a
trigger event of Q01 (query sent for immediate response) in the query
transaction yields a request for an immediate response, whereas the use of
trigger event Q02 (query send for deferred response) requests a deferred
response. In the immediate mode, the responding application initiates a
message using the DSR message type. In the deferred response mode, the
responding application first acknowledges the query with a general
acknowledgment, and then later fulfills the query request with a DSR message,
using trigger event Q03 (deferred response to a query). Refer to Chapter 2,
Section 2.16, "Query Trigger Events and Message Definitions," for a full
discussion of query messages, types, definitions, triggers, and variants.
As indicated in item (a) under Section 2.16.1 in Chapter 2, the allowable
values for the filters in the QRD and QRF segments are determined among the
coordinating applications during implementation. In general, applications
responding to query transactions should define the valid filter codes for the
queries they are able to support. Applications initiating query transactions
should coordinate with these values at the time of implementation. Section
10.4.3, "SQM/SQR - schedule query message and response (event S25)," suggests a
representative set of values that might be used in querying applications for
schedule information.
Likewise, information contained in the DSP segment(s) is formatted according to
the standards and requirements laid out at the time of implementation. Data
contained in these lines of displayable information should be understood to
have lost their semantic value, and should be treated only as text.
If both the querying and responding applications support the QAK segment
introduced in Version 2.3, then the Enhanced Display Response message (message
type EDR) may be used to respond to the QRY message.
As
stated in Chapter 2, Section 2.16, "Query Trigger Events and Message
Definitions," original mode record-oriented query and response messages are
defined in the individual chapters. This section defines the messages used in
Original Mode record-oriented queries and responses for schedule information.
Refer to Chapter 2, Section 2.16, "Query Trigger Events and Message
Definitions," for a full discussion of query messages.
This section also defines the format of the response message for SQL queries,
Virtual Table Queries (VQQ) and Stored Procedure Request (SPQ) queries, when
the Enhanced Response Format Code field of their respective defining segments
contains the code R. This code indicates that the response should be
given in the record-oriented format. When using any of these three enhanced
mode queries with a record-oriented response indicator, use only the response
message definition from this section. The remainder of this section pertains
only to original mode record-oriented queries.
Original
Mode record-oriented query transactions are initiated from the querying
application using the Schedule Query (SQM) to request information about a
filler application's schedule(s). The filler application responds to these
requests, using the Schedule Query Response (SQR) message to either return the
requested information, or to signal that an interfacing error of some kind has
occurred. The definitions for the SQM message and the SQR response are listed
below.
SQM^S25 |
Schedule Query |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
[ ARQ |
Appointment Request |
10 |
[ APR ] |
Appointment Preferences |
10 |
[ PID ] |
Patient Identification |
3 |
{ RGS |
Resource Group Segment |
10 |
[ { AIS |
Appointment Information - Service |
10 |
[ APR ] |
Appointment Preferences |
10 |
} |
||
] |
||
[ { AIG |
Appointment Information - General Resource |
10 |
[ APR ] |
Appointment Preferences |
10 |
} |
||
] |
||
[ { AIP |
Appointment Information - Personnel Resource |
10 |
[ APR ] |
Appointment Preferences |
10 |
} |
||
] |
||
[ { AIL |
Appointment Information - Location Resource |
10 |
[ APR ] |
Appointment Preferences |
10 |
} |
||
] |
||
} |
||
] |
||
[ DSC ] |
Continuation Pointer |
2 |
SQR^S25 |
Schedule Query Response |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
QAK |
Query Acknowledgment |
2 |
[ { SCH |
Schedule Activity Information |
10 |
[ { NTE } ] |
Notes and Comments |
2 |
[ PID |
Patient Identification |
3 |
[ PV1 ] |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info |
3 |
[ DG1 ] |
Diagnosis |
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 |
} |
||
] |
||
[ { AIP |
Appointment Information - Personnel Resource |
10 |
[ {NTE} ] |
Notes and Comments |
2 |
} |
||
] |
||
[ { AIL |
Appointment Information - Location Resource |
10 |
[ {NTE} ] |
Notes and Comments |
2 |
} |
||
] |
||
} |
||
} |
||
] |
||
[ DSC ] |
Continuation Pointer |
2 |
If
the deferred response mode (as defined in Chapter 2, Section 2.18, "Original
Mode Deferred Access") is required, then modify the above message definition as
follows:
* A code of D for "deferred" appears in the third field of the QRD
segment, "Query Priority."
* The acknowledgment of the initial SQM message is a general acknowledgment
(ACK).
* The SQR message is sent as if it were an unsolicited message. The original
querying application responds with a general acknowledgment message (ACK).
There is only one trigger event defined for schedule information queries. This
trigger event is used for all original mode record-oriented schedule
information queries. The specification of information to return in the query
response is defined by the values provided in certain fields of the QRD and QRF
segments.
QRD-2-query format code is assumed to hold the value R,
indicating that the response should be in a record-oriented format. A value of
D is invalid in QRD-2-query format code, in conjunction with this
trigger event, and should generate an error.
QRD-9-what subject filter defines the kind of information that the query
is requesting. The following codes are suggested as possible candidates for
this field, defining the different kinds of scheduling information requests
that might be required by querying applications. Refer to HL7 table 0048 -
What subject filter for valid values.
Value |
Description |
SAL |
All schedule related information, including open slots, booked slots, blocked slots |
SOP |
Open slots on the identified schedule |
SBK |
Booked slots on the identified schedule |
SBL |
Blocked slots on the identified schedule |
SSA |
Time slots available for a single appointment |
SSR |
Time slots available for a recurring appointment |
QRF-1-where
subject filter allows the query to specify the department, the system, or
the subsystem.
Any remaining definition and filtering of the query should be achieved by
supplying information in the chapter-specific segments that fall between the
QRF segment and DSC segment in the message definition.
The new enhanced mode queries, introduced in Version 2.3, use the message definitions and responses defined in Chapter 2. Refer to Section 2.20, "Enhanced Query Mode Response Messages," for more information on those query transactions.
The
ARQ segment defines a request for the booking of an appointment. It is used in
transactions sent from an application acting in the role of a placer.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
75 |
EI |
R |
00860 |
Placer Appointment ID | ||
2 |
75 |
EI |
C |
00861 |
Filler Appointment ID | ||
3 |
5 |
NM |
C |
00862 |
Occurrence Number | ||
4 |
22 |
EI |
O |
00218 |
Placer Group Number | ||
5 |
200 |
CE |
O |
00864 |
Schedule ID | ||
6 |
200 |
CE |
O |
00865 |
Request Event Reason | ||
7 |
200 |
CE |
O |
0276 |
00866 |
Appointment Reason | |
8 |
200 |
CE |
O |
0277 |
00867 |
Appointment Type | |
9 |
20 |
NM |
O |
00868 |
Appointment Duration | ||
10 |
200 |
CE |
O |
00869 |
Appointment Duration Units | ||
11 |
53 |
DR |
O |
Y |
00870 |
Requested Start Date/Time Range | |
12 |
5 |
ST |
O |
00871 |
Priority-ARQ | ||
13 |
100 |
RI |
O |
00872 |
Repeating Interval | ||
14 |
5 |
ST |
O |
00873 |
Repeating Interval Duration | ||
15 |
48 |
XCN |
R |
Y |
00874 |
Placer Contact Person | |
16 |
40 |
XTN |
O |
Y |
00875 |
Placer Contact Phone Number | |
17 |
106 |
XAD |
O |
Y |
00876 |
Placer Contact Address | |
18 |
80 |
PL |
O |
00877 |
Placer Contact Location | ||
19 |
48 |
XCN |
R |
Y |
00878 |
Entered By Person | |
20 |
40 |
XTN |
O |
Y |
00879 |
Entered By Phone Number | |
21 |
80 |
PL |
O |
00880 |
Entered By Location | ||
22 |
75 |
EI |
O |
00881 |
Parent Placer Appointment ID | ||
23 |
75 |
EI |
O |
00882 |
Parent Filler Appointment ID |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains placer application's permanent identifier for
the appointment request (and the scheduled appointment itself, when confirmed
as booked by the filler application). This is a composite field. Refer to
Chapter 2, Section 2.8.15, "EI - entity identifier," for a description of the
EI data type and its components and subcomponents.
The first component is a string that identifies an individual appointment
request, or booked appointment. It is assigned by the placer application, and
it identifies an appointment request, and the subsequent scheduled appointment,
uniquely among all such requests and/or booked appointments from a particular
requesting application. If the placer appointment ID identifies a parent of a
repeating schedule request, then the individual scheduled child appointments
can be uniquely identified either by a new placer appointment ID or the
parent's placer appointment ID plus an occurrence number, specified in
ARQ-3-occurrence number.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
Components:
<entity identifier (ST)> ^ <namespace ID (ST)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the filler application's permanent identifier
for the appointment request (and the scheduled appointment itself, when
confirmed as a booked slot by the filler application). This is a composite
field. Refer to Chapter 2, Section 2.8.15, "EI - entity identifier," for a
description of the EI data type and its components and subcomponents.
The first component is a string that identifies an individual appointment
request, or booked appointment. It is assigned by the filler application, and
it identifies an appointment request and the subsequent scheduled appointment,
uniquely among all such requests and/or booked appointments from a particular
processing application. If the filler appointment ID identifies a parent of a
repeating schedule request, then the individual scheduled child appointments
can be uniquely identified either by a new filler appointment ID or the
parent's filler appointment ID plus an occurrence number, specified in
ARQ-3-occurrence number.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
This is a conditionally required field. On initial request messages and other
messages where a filler has not yet assigned a filler appointment ID, this
field should not contain a value. In all other subsequent messages, where a
filler application has assigned a filler appointment ID and communicated it to
other applications, this field is required.
Definition:
This field is used in conjunction with the placer appointment ID and/or the
filler appointment ID to uniquely identify an individual occurrence (a child)
of a parent repeating schedule appointment.
This field is conditionally required. If the transaction using this segment is
meant to apply only to one occurrence of a repeating appointment, and an
occurrence number is required to uniquely identify the child appointment (that
is, the child does not have a separate and unique placer appointment ID or
filler appointment ID), then this field is required.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field allows a placer application to group sets of
appointment requests together, and subsequently to identify the group.
The first component is a string that identifies a group of appointment
requests. It is assigned by the placer application, and it identifies an
appointment group uniquely among all such groups of requests from a particular
requesting application.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code for the schedule in which
this appointment should be (or is) booked. This field is provided for
situations in which filler applications maintain multiple schedules, and in
which a particular resource or set of resources is controlled by more than one
of those schedules.
If a new appointment must be booked, it may be necessary to provide a schedule
ID to uniquely identify the intended slot(s) being requested in the
transaction. After the request has been assigned to one or more slots,
however, the filler application should assign a unique filler appointment ID
(see Sections 10.5.1.1, "Placer appointment ID (EI) 00860," and 10.5.1.2,
"Filler appointment ID (EI) 00861 )." This filler appointment ID, as its
definition indicates, should uniquely identify the appointment among all such
requests and appointments within the filler application. This means that, once
assigned, the filler appointment ID should uniquely identify the appointment
(either as a request or as a booked appointment) without a need to provide the
schedule ID too. As a cautionary note regarding implementation, if the filler
appointment ID would not otherwise be unique, it may be necessary to include
the schedule ID as part of the filler appointment ID. This can be done either
by prefixing the appointment ID with the schedule ID, or by appending the
schedule ID to the appointment ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the identifier code for the reason that the
request event is being triggered. This field may contain a code describing the
cancel reason, the delete reason, the discontinue reason, the add reason, or
any other code describing the reason that a specific event is occurring.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the identifier code for the reason that the
appointment is to take place. This field may contain a Universal Service ID
describing the observation/test/battery/procedure or other activity that is to
be performed during the requested appointment, similar to the Universal Service
ID defined for the OBR segment in Chapter 4 on Order Entry. It may also
contain a site-specific code describing a pre-defined set of reasons that an
appointment may be set to occur. This code can be based on local and/or
universal codes. The use of universal codes is recommended. Refer to
user-defined table 0276 - Appointment reason codes, below, for suggested
codes.
Value |
Description |
ROUTINE |
Routine appointment - default if not valued |
WALKIN |
A previously unscheduled walk-in visit |
CHECKUP |
A routine check-up, such as an annual physical |
FOLLOWUP |
A follow up visit from a previous appointment |
EMERGENCY |
Emergency appointment |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code for the type of appointment
being requested. Refer to user-defined table 0277 - Appointment type
codes for suggested codes.
Value |
Description |
Normal |
Routine schedule request type - default if not valued |
Tentative |
A request for a tentative (e.g., "penciled in") appointment |
Complete |
A request to add a completed appointment, used to maintain records of completed appointments that did not appear in the schedule (e.g., STAT, walk-in, etc.) |
Definition:
This field contains the amount of time being requested for the appointment.
In cases of requests for repeating appointments, this field describes the
duration of one instance of the appointment. If this field is unvalued, then
the institution's standard duration for the type of appointment requested will
be assumed.
The appointment duration field must contain a positive, non-zero number. A
negative number or zero (0) is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used in
expressing the ARQ-9-appointment duration field. This field should be
valued according to the recommendations in Chapters 2 and 7. If this component
is not valued, the ISO base unit of seconds (code s) will be assumed.
Refer to Chapter 7, Figures 7-10 through 7-13, for a list of ISO
and ANSI+ unit codes.
Components:
<range start date/time (TS)> ^ <range end date/time (TS)>
Definition: This field contains the date and time that the appointment is
requested to begin, in the form of a date/time range. The first component
contains the earliest date and time that the appointment may be scheduled to
begin. The second component contains the latest date and time that the
appointment may be scheduled to begin.
The TS (time stamp) data type allows for two components: the time stamp, and a
degree of precision. If used, the degree of precision should be separated from
the time stamp by a subcomponent delimiter.
If only the range start date/time has been provided, then the range end
date/time is assumed to be infinity. Using this scenario is equivalent to
requesting the next available slot on/after a particular date and time. If
only the range end date/time has been provided, then the range start date/time
is assumed to be immediate. Using this scenario is equivalent to requesting
the appointment start some time between the current date and time, and the
specified range end date/time. Requesting an appointment when the range start
and range end date/time are the same is equivalent to requesting a specific
slot on a schedule. If this field is unvalued, then the filler application
will assume that the next available slot should be scheduled, using the
institution's processing rules for scheduling appointments.
This field may repeat. Repetitions of this field are used to construct a list
of acceptable ranges. Repetitions of this field are connected with a logical
OR to construct this list. This procedure allows applications to provide
multiple preferences for the scheduling of appointments. Applications should
take steps to ensure that nonsensical ranges are not indicated in this field
(for example, redundant ranges).
Examples:
Schedule the appointment to begin at some time between 8:00AM on Tuesday, May
17th, 1994 and 12:00PM on Friday, May 20th, 1994 local time:
...|199405170800^199405201200|...
Schedule the appointment in the next available slot on/after 6:00AM on Monday,
April 25th, 1994 local time:
...|199405250600^|...
Note: The field value ...|199405250600|... is equivalent to making the
above request, according to the HL7 rules for processing fields.
Schedule the appointment in the next available slot on/before
6:00AM on Monday, April 25th, 1994 local time:
...|^199405250600|...
Schedule the appointment in the next available slot:
...||...
Schedule the appointment to begin on any weekday during the two weeks beginning
Monday, April 4th 1994. In this example, the degree of precision
(sub)component of the time stamp is used to indicate that the date/time ranges
refer to the institution's standard operating day:
...|199404040000&D^199404080000&D~199404110000&D^199404150000&D|...
Schedule the appointment in the next available slot that does not occur during
the May, 1994 HL7 Working Group Meeting:
...|^199405161600~199405230800^|...
Schedule the appointment to begin on/before 4:00PM on Thursday, December 23rd,
1993, or any weekday between Monday, December 27th and Thursday, December 30th,
or on/after 8:00AM on Monday, January 3rd, 1994:
...|^199312231600~199312270000&D^199312300000&D~199401030800^|...
Definition: This field contains the urgency of the request. The definition of this field is equivalent to the definition of the priority component of the Quantity/Timing data type given in the Order Entry chapter (Chapter 4), Section 4.4.6, "Priority component."
Components:
<repeat pattern (IS)> ^ <explicit time interval (ST)>
Definition: This field contains the interval between repeating appointments.
The default setting indicates that the appointment should occur once, if the
component is not valued. The definition of this field is equivalent to the
definition of the interval component of the Quantity/Timing data type given in
the Order Entry chapter (Chapter 4), Section 4.4.2, "Interval component."
If an explicit time interval is specified for the repeat pattern, then it
specifies the actual time(s) at which the appointment should be scheduled. The
ARQ-11-requested start date/time range ought to indicate the first
repetition that should occur.
Note: The subcomponent delimiter defined for the Interval component of
the Quantity/Timing field definition has been replaced by a component delimiter
for this field.
Definition: This field indicates how long the appointment repetitions should continue, once they have begun. The default setting indicates that the appointment should occur once. If the Interval Duration is defined as indefinitely repeating, the repetition of this appointment can only be stopped by using a discontinue event. The definition of this field is equivalent to the definition of the Interval component of the Quantity/Timing field given in the Order Entry chapter (Chapter 4), Section 4.4.3, "Duration component," with the exception of the default value.
Components:
<ID number (ST)> ^ <family name (ST)> & <last name prefix
(ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^
<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^
<degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning
authority (HD)> ^ <name type (ID)> ^ <identifier check digit
(ST)> ^ <code identifying the check digit scheme employed (ID)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the person responsible for requesting the
scheduling of a requested appointment. This person could be the same person
responsible for executing the actual appointment, or it could be the provider
requesting that an appointment be made on behalf of the patient, with another
provider.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number used to contact the placer
contact person.
Components:
<street address (ST)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^
<country (ID)> ^ <address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census
tract (IS)> ^ <address representation code (ID)>
Definition: This field contains the address used to contact the placer contact
person.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ < location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a code that identifies the location of the
placer contact person.
Components:
<ID number (ST)> ^ <family name (ST)> & <last name prefix
(ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^
<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^
<degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning
authority (HD)> ^ <name type (ID)> ^ <identifier check digit
(ST)> ^ <code identifying the check digit scheme employed (ID)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the person responsible for entering the
request for the scheduling of an appointment. It is included to provide an
audit trail of persons responsible for the request. This person may be someone
other than the placer contact person, who is responsible for entering orders
and requests.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number used to contact the
ARQ-19-entered by person.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a code that identifies the location of the
entered by person.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field relates a child to its parent, when a parent-child
relationship exists. It contains the placer application's permanent identifier
for the parent of the appointment request. This is a composite field.
The first component is a string that identifies the parent appointment request.
It is assigned by the placer application, and identifies an appointment request
uniquely among all such requests from a particular requesting application.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier in Chapter 2
describes the structure and content of these components with respect to the EI
data type.
Components:
<entity identifier (ST)> ^ <namespace ID (ID)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field relates a child to its parent, when a parent-child
relationship exists. It contains the filler application's permanent identifier
for the parent of the appointment request. This is a composite field.
The first component is a string that identifies the parent appointment request.
It is assigned by the filler application, and identifies an appointment request
uniquely among all such requests on a particular processing application.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
The
SCH segment contains general information about the scheduled appointment.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
75 |
EI |
C |
00860 |
Placer Appointment ID | ||
2 |
75 |
EI |
C |
00861 |
Filler Appointment ID | ||
3 |
5 |
NM |
C |
00862 |
Occurrence Number | ||
4 |
22 |
EI |
O |
00218 |
Placer Group Number | ||
5 |
200 |
CE |
O |
00864 |
Schedule ID | ||
6 |
200 |
CE |
R |
00883 |
Event Reason | ||
7 |
200 |
CE |
O |
0276 |
00866 |
Appointment Reason | |
8 |
200 |
CE |
O |
0277 |
00867 |
Appointment Type | |
9 |
20 |
NM |
O |
00868 |
Appointment Duration | ||
10 |
200 |
CE |
O |
00869 |
Appointment Duration Units | ||
11 |
200 |
TQ |
R |
Y |
00884 |
Appointment Timing Quantity | |
12 |
48 |
XCN |
O |
Y |
00874 |
Placer Contact Person | |
13 |
40 |
XTN |
O |
00875 |
Placer Contact Phone Number | ||
14 |
106 |
XAD |
O |
Y |
00876 |
Placer Contact Address | |
15 |
80 |
PL |
O |
00877 |
Placer Contact Location | ||
16 |
38 |
XCN |
R |
Y |
00885 |
Filler Contact Person | |
17 |
40 |
XTN |
O |
00886 |
Filler Contact Phone Number | ||
18 |
106 |
XAD |
O |
Y |
00887 |
Filler Contact Address | |
19 |
80 |
PL |
O |
00888 |
Filler Contact Location | ||
20 |
48 |
XCN |
R |
Y |
00878 |
Entered by Person | |
21 |
40 |
XTN |
O |
Y |
00879 |
Entered by Phone Number | |
22 |
80 |
PL |
O |
00880 |
Entered by Location | ||
23 |
75 |
EI |
O |
00881 |
Parent Placer Appointment ID | ||
24 |
75 |
EI |
C |
00882 |
Parent Filler Appointment ID | ||
25 |
200 |
CE |
O |
0278 |
00889 |
Filler Status Code |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the placer application's permanent identifier
for the appointment request (and the scheduled appointment itself, when it has
been confirmed as a booked slot by the filler application). This is a
composite field.
The first component is a string that identifies an individual appointment
request, or a booked appointment. It is assigned by the placer application,
and identifies an appointment request, and the subsequent scheduled
appointment, uniquely among all such requests and/or booked appointments from a
particular requesting application. If SCH-1-placer appointment ID
identifies a parent of a repeating schedule request, then the individual child
scheduled appointments can be uniquely identified either by a new
SCH-1-placer appointment ID or by SCH-23-parent placer appointment
ID plus an SCH-3-occurrence number.
The second component contains the assigning authority identifying information.
Section 2.8.15, "EI - entity identifier," in Chapter 2 describes the structure
and content of these components with respect to the EI data type.
If a schedule request originates from a placer it MUST have a placer
appointment ID. If the filler sends responses, it may use the placer
appointment ID and/or assign a filler appointment ID (which it would echo back
to the placer to enable the placer application to associate the two). If the
placer appointment ID is not present, the filler appointment ID must be present
and vice versa.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the filler application's permanent identifier
for the appointment request (and the scheduled appointment itself, when it has
been confirmed as a booked slot by the filler application). This is a
composite field.
The first component is a string of up to fifteen characters that identifies an
individual appointment request, or a booked appointment. It is assigned by the
filler application, and identifies an appointment request, and the subsequent
scheduled appointment, uniquely among all such requests and/or booked
appointments from a particular processing application. If SCH-2-filler
appointment ID identifies a parent of a repeating schedule request, then
the individual child scheduled appointments can be uniquely identified either
by a new SCH-2-filler appointment ID or by SCH-25-parent filler
appointment ID plus an SCH-3-occurrence number.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
Definition:
This field is used in conjunction with SCH-1-placer appointment ID
and/or SCH-2-filler appointment ID to uniquely identify an individual
occurrence (a child) of a parent repeating schedule appointment.
This field is conditionally required. If the transaction using this segment is
intended to apply only to one occurrence of a repeating appointment, and an
occurrence number is required to uniquely identify the child appointment (that
is, the child does not have a separate and unique SCH-1-placer appointment
ID or SCH-2-filler appointment ID), then this field is required.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field allows a placer application to group sets of
appointment requests together, and subsequently to identify the group.
The first component is a string that identifies a group of appointment
requests. It is assigned by the placer application, and it identifies an
appointment group uniquely among all such groups of requests from a particular
requesting application.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code for the schedule in which
this appointment is (or will be) booked. This field is provided for instances
in which filler applications maintain multiple schedules, and when a particular
resource or set of resources is controlled by more than one of those
schedules.
This field is provided on the SCH segment for informational purposes to
applications fulfilling the placer, querying and auxiliary roles.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code for the reason that the
notification event was triggered. This field may contain a code describing the
cancel reason, the delete reason, the discontinue reason, the add reason, the
block reason or any other code describing the reason that a specific event will
occur.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code for the reason that the
appointment is to take place. This field may contain a Universal Service ID
describing the observation/test/battery/procedure or other activity that is to
take place during the requested appointment, similar to the Universal Service
ID defined for the OBR segment in the Order Entry chapter (Chapter 4). It may
also contain a site-specific code describing a pre-defined set of reasons that
an appointment may be set to occur. This code can be based on local and/or
universal codes. The use of universal codes is recommended. Refer to
user-defined table 0276 - Appointment reason codes for suggested codes.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the identifier code for the type of
appointment. Refer to user-defined table 0277 - Appointment type codes
for suggested codes.
Definition:
This field specifies the amount of time requested and allotted for the
appointment. In cases of repeating appointments, this field describes the
duration of one instance of the appointment. If this field is unvalued, then
the institution's standard duration for the type of appointment requested will
be assumed.
The appointment duration field must contain a positive, non-zero number. A
negative number or zero (0) is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing the ARQ-9-appointment duration field. This field should be
valued according to the recommendations in Chapters 2 and 7. If this component
is not valued, the ISO base unit of seconds (code "s") is assumed.
Refer to Chapter 7, Figures 7-10 through 7-13, for a list of ISO
and ANSI+ unit codes.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (CM)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ST)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences (NM)>
Definition: This field contains the scheduled appointment's timing and
quantity, as scheduled by the filler application. Chapter 4, Section 4.4,
""Quantity/Timing (TQ) Definition," fully describes the components and the
appropriate data values for the components of this field.
Components:
<ID number (ST)> ^ <family name (ST)> & <last name prefix
(ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^
<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^
<degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning
authority (HD)> ^ <name type (ID)> ^ <identifier check digit
(ST)> ^ <code identifying the check digit scheme employed (ID)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the person responsible for requesting the
scheduling of a requested appointment. Most often, this person will be the
same person responsible for executing the appointment.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number used to contact the
SCH-12-placer contact person.
Components:
<street address (ST)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^
<country (ID)> ^ <address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census
tract (IS)> ^ <address representation code (ID)>
Definition: This field contains the address used to contact the
SCH-12-placer contact person.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a code that identifies the location of the
SCH-12-placer contact person.
Components:
<ID number (ST)> ^ <family name (ST)> & <last name prefix
(ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^
<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^
<degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning
authority (HD)> ^ <name type (ID)> ^ <identifier check digit
(ST)> ^ <code identifying the check digit scheme employed (ID)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the person responsible for the scheduling of
the requested appointment. Most often, this person will be the same person
responsible for maintaining the schedule and for reviewing appointment
requests.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number used to contact the
SCH-16-filler contact person.
Components:
<street address (ST)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^
<country (ID)> ^ <address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census
tract (IS)> ^ <address representation code (ID)>
Definition: This field contains the address used to contact the
SCH-16-filler contact person..
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a code that identifies the location of the
SCH-16-filler contact person.
Components:
<ID number (ST)> ^ <family name (ST)> & <last name prefix
(ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^
<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^
<degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning
authority (HD)> ^ <name type (ID)> ^ <identifier check digit
(ST)> ^ <code identifying the check digit scheme employed (ID)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the person responsible for entering the
request for the scheduling of an appointment. It is included to provide an
audit trail of persons responsible for the request. This person may be someone
other than the placer contact person, who is responsible for entering orders
and requests.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number used to contact the
ARQ-19-entered by person.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a code that identifies the location of the
entered by person.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field relates a child to its parent, when a parent-child
relationship exists. It contains the placer application's permanent identifier
for the parent of the appointment request. This is a composite field.
The first component is a string that identifies the parent appointment request.
It is assigned by the placer application, and identifies an appointment request
uniquely among all such requests from a particular requesting application.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
Components:
<entity identifier (ST)> ^ <namespace ID (ID)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field relates a child to its parent, when a parent-child
relationship exists. It contains the filler application's permanent identifier
for the parent of the appointment request. This is a composite field.
The first component is a string that identifies the parent appointment request.
It is assigned by the filler application, and it identifies an appointment
request uniquely among all such requests on a particular processing
application.
The second through fourth components contain the assigning authority
identifying information. Section 2.8.15, "EI - entity identifier," in Chapter
2 describes the structure and content of these components with respect to the
EI data type.
This is a conditionally required field. On initial messages where a filler has
not yet assigned a filler appointment ID, this field should not contain a
value. In all other subsequent messages, where a filler application has
assigned a filler appointment ID, this field is required.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the status of the
appointment with respect to the filler application. Refer to user-defined
table 0278 - Filler status codes for suggested codes.
The
RGS segment is used to identify relationships between resources identified for
a scheduled event. This segment can be used, on a site specified basis, to
identify groups of resources that are used together within a scheduled event,
or to describe some other relationship between resources. To specify related
groups of resources within a message, begin each group with an RGS segment, and
then follow that RGS with one or more of the Appointment Information segments
(AIG, AIL, AIS, or AIP).
If a message does not require any grouping of resources, then specify a single
RGS in the message, and follow it with all of the Appointment Information
segments for the scheduled event. (At least one RGS segment is required in
each message - even if no grouping of resources is required - to allow parsers
to properly understand the message.)
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
SI |
R |
01203 |
Set ID - RGS | ||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action Code | |
3 |
200 |
CE |
O |
01204 |
Resource Group ID |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 table 0206 - Segment action code in Chapter 2, Section 2.23.4.2,
"Action code/unique identifier mode update definition," for valid values.
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code describing the group of
resources following this RGS segment.
The
AIS segment contains information about various kinds of services that can be
scheduled. Services included in a transaction using this segment are assumed
to be controlled by a schedule on a schedule filler application. Services not
controlled by a schedule are not identified on a schedule request using this
segment.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00890 |
Set ID - AIS | ||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action Code | |
3 |
200 |
CE |
R |
00238 |
Universal Service ID | ||
4 |
26 |
TS |
C |
01202 |
Start Date/Time | ||
5 |
20 |
NM |
C |
00891 |
Start Date/Time Offset | ||
6 |
200 |
CE |
C |
00892 |
Start Date/Time Offset Units | ||
7 |
20 |
NM |
O |
00893 |
Duration | ||
8 |
200 |
CE |
O |
00894 |
Duration Units | ||
9 |
10 |
IS |
C |
0279 |
00895 |
Allow Substitution Code | |
10 |
200 |
CE |
C |
0278 |
00889 |
Filler Status Code |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 table 0206 - Segment action code in Chapter 2, Section 2.23.4.2,
"Action code/unique identifier mode update definition," for valid values.
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains an identifier code for a service to be
scheduled. This field may contain a Universal Service ID describing the
observation/test/battery/procedure or other activity that is to be performed
during the requested appointment, similar to the Universal Service ID defined
for the OBR segment in the Order Entry chapter (Chapter 4). This code can be
based on local and/or universal codes. The use of universal codes is
recommended.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time
This field is conditionally required. If a value for AIS-5-start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIS-5-start
date/time offset and any valid time unit code in AIS-6-start date/time
offset units.
Definition:
This field contains the offset this service needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field allows the application to identify that the service is required for the
appointment at a different time than the appointment's start date/time. The
first component contains the offset amount. An offset of zero (0), or an
unvalued field indicates that the service is required at the start date/time of
the appointment.
A positive offset (an unsigned or positive number) indicates that the service
is required after the appointment's start date/time. Specifying a negative
offset indicates that the service is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIS-5-start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIS-5-start
date/time offset and any valid time unit code in AIS-6-start date/time
offset units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing the start date/time offset. This field should be valued according
to the recommendations in Chapters 2 and 7. If this field is not valued, the
ISO base unit of seconds (code s) will be assumed. Refer to Chapter 7,
Figures 7-10 through 7-13, for a list of ISO and ANSI+ unit
codes.
This field is conditionally required. If a value for AIS-5-start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for this appointment, if different from the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing the duration. This field should be valued according to the
recommendations in Chapters 2 and 7. If this field is not valued, the ISO base
unit of seconds (code s) will be assumed. Refer to Chapter 7,
Figures 7-10 through 7-13, for a list of ISO and ANSI+ unit codes.
Definition:
This field contains a code indicating whether the identified resource can be
substituted with an equivalent resource by the filler application. Refer to
user-defined table 0279 - Allow substitution codes for suggested
codes.
Value |
Description |
No |
Substitution of this resource is not allowed |
Confirm |
Contact the Placer Contact Person prior to making any substitutions of this resource |
Notify |
Notify the Placer Contact Person, through normal institutional procedures, that a substitution of this resource has been made |
Yes |
Substitution of this resource is allowed |
This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code that describes the requested/scheduled
status of the resource or activity, from the point of view of the filler
application. Refer to user-defined table 0278 - Filler status codes for
suggested codes.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
AIG segment contains information about various kinds of resources (other than
those with specifically defined segments in this chapter) that can be
scheduled. Resources included in a transaction using this segment are assumed
to be controlled by a schedule on a schedule filler application. Resources not
controlled by a schedule are not identified on a schedule request using this
segment. Resources described by this segment are general kinds of resources,
such as equipment, that are identified with a simple identification code.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00896 |
Set ID - AIG | ||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action Code | |
3 |
200 |
CE |
C |
00897 |
Resource ID | ||
4 |
200 |
CE |
R |
00898 |
Resource Type | ||
5 |
200 |
CE |
O |
Y |
00899 |
Resource Group | |
6 |
5 |
NM |
O |
00900 |
Resource Quantity | ||
7 |
200 |
CE |
O |
00901 |
Resource Quantity Units | ||
8 |
26 |
TS |
C |
01202 |
Start Date/Time | ||
9 |
20 |
NM |
C |
00891 |
Start Date/Time Offset | ||
10 |
200 |
CE |
C |
00892 |
Start Date/Time Offset Units | ||
11 |
20 |
NM |
O |
00893 |
Duration | ||
12 |
200 |
CE |
O |
00894 |
Duration Units | ||
13 |
10 |
IS |
C |
0279 |
00895 |
Allow Substitution Code | |
14 |
200 |
CE |
C |
0278 |
00889 |
Filler Status Code |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 table 0206 - Segment action code in Chapter 2, Section 2.23.4.2,
"Action code/unique identifier mode update definition," for valid values.
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the ID number and name of the resource being
requested or scheduled for an appointment. This field is used to identify a
specific resource being requested, or a specific resource that has been
scheduled for an appointment. If the specific resource is not known but the
type of resource is, AIG-4-resource type is used to identify the type of
resource required or scheduled.
At a minimum, the ID number component should be supplied to identify either the
specific resource being requested or the specific resource that has been
scheduled. For inter-enterprise communications, for which a shared ID number
may not be available, the minimum components required to uniquely identify a
resource may be defined by site-specific negotiations.
This field is conditionally required for this segment. In new schedule request
messages, it is required if the request asks that a specific resource be
scheduled. For all other request messages, the specific resource should be
identified if the information is available (either because a specific resource
was initially requested, or because the filler application returned the ID of
the specific resource that has been scheduled).
This field is required for all unsolicited transactions from the filler
application.
This field is optional for all query transactions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field identifies the role of the resource requested/scheduled
for this appointment. For requests, if a specific resource is not identified
in AIG-3-resource ID, then this field identifies the type of resource
that should be scheduled by the filler application. At a minimum, the type of
the identifier component should be valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field identifies the requested resource as a member of the
indicated group. If, in a Schedule Request Message (SRM), no specific resource
is requested, but a resource type is requested, this field can be used to
further qualify the type of resource being requested.
Definition: This field contains the quantity of the specified resource or resource type identified in either or both of the preceding two fields. If it is not valued, this field defaults to a value of one (1).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the units of the resource requested, whose
quantity is given in the preceding field. This field should be valued
according to the recommendations in Chapters 2 and 7. If this field is not
valued, the unit of each (code "ea") will be assumed. Refer to Chapter 7,
Figures 7-10 through 7-13, for a list of ISO and ANSI+ unit codes.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time
This field is conditionally required. If a value for AIG-9-start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIG-9-start
date/time offset and any valid time unit code in AIG-10-start date/time
offset units.
Definition:
This field contains the offset that this resource needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field indicates to the application that the resource is required for the
appointment at a different time than the appointment's start date/time. The
first component indicates the offset amount. An offset of zero (0), or an
unvalued field, indicates that the resource is required at the start date/time
of the appointment.
A positive offset (an unsigned or positive number) indicates that the resource
is required after the appointment's start date/time. Specifying a negative
offset indicates that the resource is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIG-8-start date/time
is not provided, then a value is required for this field. To specify that
there is no difference between the appointment's start date/time and the
resource's start date/time either replicate the appointment's start date/time
into this field, or specify an offset of zero (0) in AIG-9-start date/time
offset and any valid time unit code in AIG10-start date/time offset
units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing AIG-9-start date/time offset. This field should be valued
according to the recommendations made in Chapters 2 and 7. If this field is
not valued, the ISO base unit of seconds (code "s") will be assumed.
Refer to Chapter 7, Figures 7-10 through 7-13, for a list of ISO
and ANSI+ unit codes.
This field is conditionally required. If a value for AIG-9-start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for this appointment, if it is different than the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing the AIG-11-duration field. This field should be valued
according to the recommendations in Chapters 2 and 7. If this field is not
valued, the ISO base unit of seconds (code "s") will be assumed. Refer
to Chapter 7, Figures 7-10 through 7-13, for a list of ISO and
ANSI+ unit codes.
Definition:
This field contains a code indicating whether the identified resource can be
substituted with an equivalent resource by the filler application. Refer to
user-defined table 0279 - Allow substitution codes for suggested
codes.
This field is conditionally required. It is required for all request messages.
It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code that describes the requested/scheduled
status of scheduling resource or activity, from the point of view of the filler
application. Refer to user-defined table 0278 - Filler status codes for
suggested codes.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
AIL segment contains information about location resources (meeting rooms,
operating rooms, examination rooms, or other locations) that can be scheduled.
Resources included in a transaction using this segment are assumed to be
controlled by a schedule on a schedule filler application. Resources not
controlled by a schedule are not identified on a schedule request using this
segment. Location resources are identified with this specific segment because
of the specific encoding of locations used by the HL7 specification.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
SI |
R |
00902 |
Set ID - AIL | ||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action Code | |
3 |
80 |
PL |
C |
00903 |
Location Resource ID | ||
4 |
200 |
CE |
R |
00904 |
Location Type-AIL | ||
5 |
200 |
CE |
O |
00905 |
Location Group | ||
6 |
26 |
TS |
C |
01202 |
Start Date/Time | ||
7 |
20 |
NM |
C |
00891 |
Start Date/Time Offset | ||
8 |
200 |
CE |
C |
00892 |
Start Date/Time Offset Units | ||
9 |
20 |
NM |
O |
00893 |
Duration | ||
10 |
200 |
CE |
O |
00894 |
Duration Units | ||
11 |
10 |
IS |
C |
0279 |
00895 |
Allow Substitution Code | |
12 |
200 |
CE |
C |
0278 |
00889 |
Filler Status Code |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 table 0206 - Segment action code in Chapter 2, Section 2.23.4.2,
"Action code/unique identifier mode update definition," for valid values
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a coded identification of the location being
requested or scheduled for an appointment. This field is used to identify a
specific location being requested, or a specific location which has been
scheduled for an appointment. If the specific location is not known but the
type of location is, AIL-4-location type-AIL is used to identify the
type of location required or scheduled. Please see Section 2.8.28, "PL -
person location," in Chapter 2 for a description of each component.
This field is conditionally required for this segment. In new schedule request
messages, it is required if the request asks that a specific location be
scheduled. For all other request messages, the specific location should be
identified if the information is available (either because a specific location
was initially requested, or because the filler application returned the coded
identification of the specific location that has been scheduled).
This field is required for all unsolicited transactions from the filler
application. It is optional for all query transactions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field identifies the role of the location requested/scheduled
for this appointment. For requests, if a specific location is not identified
in AIL-3-location resource ID, then this field identifies the type of
location that should be scheduled by the filler application. At a minimum, the
type identifier component should be valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field identifies the requested resource as a member of the
indicated group. If, in a Schedule Request Message (SRM), no specific location
is requested, but a location type is requested, AIL-5-location group can
be used to further qualify the type of resource being requested.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time
This field is conditionally required. If a value for AIL-7-start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIL-7-start
date/time offset and any valid time unit code in AIL-8-start date/time
offset units.
Definition:
This field contains the offset this resource needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field indicates to the application that the resource is required for the
appointment at a different time than the appointment's start date/time. The
first component contains the offset amount. An offset of zero (0), or an
unvalued field, indicates that the resource is required at the start date/time
of the appointment.
A positive offset (an unsigned or positive number) indicates that the resource
is required after the appointment's start date/time. Specifying a negative
offset indicates that the resource is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIL-6-start date/time
is not provided, then a value is required for this field. To specify that
there is no difference between the appointment's start date/time and the
resource's start date/time either replicate the appointment's start date/time
into this field, or specify an offset of zero (0) in AIL-7-start date/time
offset and any valid time unit code in AIL-8-start date/time offset
units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing the AIL-7-start date/time offset field. This field should be
valued according to the recommendations made in Chapters 2 and 7. If this
field is not valued, the ISO base unit of seconds (code "s") will be
assumed. Refer to Chapter 7, Figures 7-10 through 7-13, for a
list of ISO and ANSI+ unit codes.
This field is conditionally required. If a value for AIL-7-start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for this appointment, if it is different than the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used
associated with AIL-9-duration. This field should be valued according
to the recommendations made in Chapters 2 and 7. If this field is not valued,
the ISO base unit of seconds (code "s") will be assumed. Refer to
Chapter 7, Figures 7-10 through 7-13, for a list of ISO and ANSI+
unit codes.
Definition:
This field contains a code indicating whether the identified location can be
replace with an equivalent substitute location by the filler application.
Refer to user-defined table 0279 - Allow substitution codes for
suggested codes.
This field is conditionally required. It is required for all request messages.
It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code that describes the requested/scheduled
status of the location, from the point of view of the filler application.
Refer to user-defined table 0278 - Filler status codes for suggested
codes.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
AIP segment contains information about the personnel types that can be
scheduled. Personnel included in a transaction using this segment are assumed
to be controlled by a schedule on a schedule filler application. Personnel not
controlled by a schedule are not identified on a schedule request using this
segment. The kinds of personnel described on this segment include any
healthcare provider in the institution controlled by a schedule (for example:
technicians, physicians, nurses, surgeons, anesthesiologists, or CRNAs).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00906 |
Set ID - AIP | ||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action code | |
3 |
80 |
XCN |
C |
Y |
00913 |
Personnel Resource ID | |
4 |
200 |
CE |
R |
00907 |
Resource Role | ||
5 |
200 |
CE |
O |
00899 |
Resource Group | ||
6 |
26 |
TS |
C |
01202 |
Start Date/Time | ||
7 |
20 |
NM |
C |
00891 |
Start Date/Time Offset | ||
8 |
200 |
CE |
C |
00892 |
Start Date/Time Offset Units | ||
9 |
20 |
NM |
O |
00893 |
Duration | ||
10 |
200 |
CE |
O |
00894 |
Duration Units | ||
11 |
10 |
IS |
C |
0279 |
00895 |
Allow Substitution Code | |
12 |
200 |
CE |
C |
0278 |
00889 |
Filler Status Code |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 table 0206 - Segment action code in Chapter 2, Section 2.23.4.2,
"Action code/unique identifier mode update definition," for valid values.
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
<ID number (ST)> ^ <family name (ST)> & <last name prefix
(ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^
<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^
<degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning
authority (HD)> ^ <name type (ID)> ^ <identifier check digit
(ST)> ^ <code identifying the check digit scheme employed (ID)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the ID number and name of the person being
requested or scheduled for an appointment. This field is used to identify a
specific person being requested, or a specific person who has been scheduled as
a resource for an appointment. If the specific person is not known, but the
type of resource is, AIP-4-resource role is used to identify the type of
personnel resource required or scheduled. Refer to Chapter 2, Section 2.8.46,
"XCN - extended composite ID number and name for persons," for a description of
the components contained in the XCN data type.
At a minimum, the ID number component should be supplied to identify either the
specific person being requested or the specific person who has been scheduled.
For inter-enterprise communications, for which a shared ID number may not be
available, the minimum components needed to uniquely identify a person may be
defined by site-specific negotiations.
This field is conditionally required for this segment. In new schedule request
messages, it is required if the request asks that a specific person be
scheduled. For all other request messages, the specific person should be
identified if the information is available (either because a specific person
was initially requested, or because the filler application returned the ID of
the specific person who has been scheduled).
This field is required for all unsolicited transactions from the filler
application. This field is optional for all query transactions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field identifies the role of the personnel
requested/scheduled for an appointment. For requests, if a specific person is
not identified in the AIP-3-personnel resource ID field, then this field
identifies the type of person that should be scheduled by the filler
application. At a minimum, the AIP-4-resource role component should be
valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field identifies the requested resource as a member of the
indicated group. If, in a Schedule Request Message (SRM), no specific resource
is requested, but an AIP-4-resource role is requested, the
AIP-5-resource group field can be used to further qualify the type of
resource being requested.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time.
This field is conditionally required. If a value for AIP-7-start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIP-7-start
date/time offset and any valid time unit code in AIP-8-start date/time
offset units.
Definition:
This field contains the offset this resource needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field indicates to the application that the resource is required for the
appointment at a different time than the appointment's start date/time. The
first component contains the offset amount. An offset of zero (0), or an
unvalued field, indicates that the resource is required at the start date/time
of the appointment.
A positive offset (an unsigned or positive number) indicates that the resource
is required after the appointment's start date/time. Specifying a negative
offset indicates that the resource is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIP-6-start
date/time is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIP-7-start
date/time offset and any valid time unit code in AIP-8-start date/time
offset units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used for
expressing AIP-7-start date/time offset. This field should be valued
according to the recommendations made in Chapters 2 and 7. If this field is
not valued, the ISO base unit of seconds (code "s") is assumed. Refer
to Chapter 7, Figures 7-10 through 7-13, for a list of ISO and
ANSI+ unit codes.
This field is conditionally required. If a value for AIP-7-start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for an appointment, if different from the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code describing the units of time used
associated with AIP-9-duration. This field should be valued according
to the recommendations made in Chapters 2 and 7. If this field is not valued,
the ISO base unit of seconds (code "s") will be assumed. Refer to
Chapter 7, Figures 7-10 through 7-13, for a list of ISO and ANSI+
unit codes.
Definition:
This field contains a code indicating whether the identified personnel
resource can be replaced with an equivalent substitute personnel resource by
the filler application. Refer to user-defined table 0279 - Allow
substitution codes for suggested codes.
This field is conditionally required. It is required for all request messages.
It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains a code that describes the requested/scheduled
status of the personnel resource, from the point of view of the filler
application. Refer to user-defined table 0278 - Filler status codes for
suggested codes.
This field is conditionally required. It should not be valued in any request
transactions from the placer application to the filler application. It is
required for all transactions from the filler application. It is optional for
query transactions.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
APR segment contains parameters and preference specifications used for
requesting appointments in the SRM message. It allows placer applications to
provide coded parameters and preference indicators to the filler application,
to help determine when a requested appointment should be scheduled. An APR
segment can be provided in conjunction with either the ARQ segment or any of
the service and resource segments (AIG, AIS, AIP, and AIL). If an APR segment
appears in conjunction with an ARQ segment, its parameters and preference
indicators pertain to the schedule request as a whole. If the APR segment
appears with any of the service and resource segments, then its parameters and
preferences apply only to the immediately preceding service or resource.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
80 |
SCV |
O |
Y |
0294 |
00908 |
Time Selection Criteria |
2 |
80 |
SCV |
O |
Y |
0294 |
00909 |
Resource Selection Criteria |
3 |
80 |
SCV |
O |
Y |
0294 |
00910 |
Location Selection Criteria |
4 |
5 |
NM |
O |
00911 |
Slot Spacing Criteria | ||
5 |
80 |
SCV |
O |
Y |
00912 |
Filler Override Criteria |
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate parameters and preferences to
the filler application regarding the selection of an appropriate time slot for
an appointment. The first component of this field is a code identifying the
parameter or preference being passed to the filler application. The second
component is the actual data value for that parameter.
For example, if a filler application allows preference parameters to be passed
to specify a preferred start time, a preferred end time, and preferred days of
the week for the appointment, it may define the following parameter class codes
and valid data sets.
Parameter Class |
Description: Valid Values |
|---|---|
Prefstart |
The preferred start time for the appointment request, service or resource. Any legal time specification in the format HHMM, using 24-hour clock notation |
Prefend |
The preferred end time for the appointment request, service or resource. Any legal time specification in the format HHMM, using 24-hour clock notation |
Mon |
An
indicator that Monday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Tue |
An
indicator that Tuesday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Wed |
An
indicator that Wednesday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Thu |
An
indicator that Thursday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Fri |
An
indicator that Friday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Sat |
An
indicator that Saturday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Sun |
An
indicator that Sunday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Given
this set of parameter class codes and valid value sets, a placer may indicate a
preferred start time of 8:00 AM on Monday, Wednesday or Friday by specifying
the following in APR-1-time selection criteria:
...|PREFSTART^0800~MON^OK~WED^OK~FRI^OK~TUE^NO~THU^NO~SAT^NO~SUN^NO|...
The valid set of preferences should be determined by the placer and filler
applications during implementation of the interface.
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate parameters and preferences to
the filler application regarding the selection of an appropriate resource for
an appointment. The first component of this field is a code identifying the
parameter or preference being passed to the filler application. The second
component is the actual data value for that parameter.
Refer to Section 10.5.8.1, "Time selection criteria (SCV) 00908," for an
example illustrating how this mechanism works within an interface.
The valid set of preferences should be determined by the placer and filler
applications during implementation of the interface. Refer to user-defined
table 0294 - Time selection criteria parameter class codes for suggested
examples.
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate parameters and preferences to
the filler application regarding the selection of an appropriate location for
the appointment. The first component of this field is a code identifying the
parameter or preference being passed to the filler application. The second
component is the actual data value for that parameter.
Refer to Section 10.5.8.1, "Time selection criteria (SCV) 00908," for an
example of how this mechanism works within an interface.
The valid set of preferences should be determined by the placer and filler
applications during implementation of the interface. Refer to user-defined
table 0294 - Time selection criteria parameter class codes for suggested
examples.
Definition:
This field is used in queries returning lists of possible appointment slots,
or other lists of slots. If the filler application allows it, the querying
application may indicate the spacing of the slots returned to the querying
application, in relation to the requested start date/time in the ARQ segment.
The value in this field should be a positive integer, representing the number
of minutes between slot starting times that is returned in the query.
For example, if there is a request that an appointment with a duration of 1.5
hours be scheduled some time between 9:00 AM and 11:30 AM, and the
APR-4-slot spacing criteria field contains a value of 15, then the list
of slots returned should read as follows:
9:00 - 10:30
9:15 - 10:45
9:30 - 11:00
9:45 - 11:15
10:00 - 11:30
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate override parameters to the
filler application. These override parameters allow placer applications to
override specific features of filler applications such as conflict checking.
It is assumed that the placer and filler applications will pass enough
information to determine whether the requestor is allowed to override such
features. This chapter does not provide any security or permission
information.
The first component of this field is a code identifying the parameter being
passed to the filler application. The second component is the actual data
value for that parameter.
Refer to Section 10.5.8.1, "Time selection criteria (SCV) 00908," for an
example illustrating how this mechanism works within an interface.
The valid set of parameters should be determined by the placer and filler
applications during implementation of the interface.
The
patient has been seen by his primary care physician, Dr. Jones, and requires
treatment by a cardiologist. The PCP requests a new appointment with Dr.
Jensen at the North Office. The patient has requested that the appointment be
scheduled for a time between January 2nd and January 10th, 1994, and between
8:00 AM and 5:00 PM. Dr. Jensen's office responds to the request with an
appointment at the North Office at 9:30 AM on January 6, 1994.
MSH|^~\&|JONES|EWHIN|SPOCARD|EWHIN|199401010800||SRM^S01|090849JONES|P|2.3.1|||AL|AL|||<cr>
ARQ|19940047^SCH001|||||047^Referral||NORMAL|||199401020800^199401101700||||0045^Jones^Harold^S^^^MD||||3372^Effenbach^Thomas||||<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
DG1|001|I9|786.5|CHEST PAINS|199401010730|W|||||||||||||<cr>
DG1|002|I9|412|OLD MYOCARDIAL
INFARCTION|199401010730|W|||||||||||||<cr>
RGS|001|<cr>
AIP|001|032^JENSEN^HELEN|002^CARDIOLOGIST|||||||NO|<cr>
AIL|001|^NORTH OFFICE|002^CLINIC|||||||YES|<cr>
MSH|^~\&|SPOCARD|EWHIN|JONES|EWHIN|199401010802||ACK|021244SPOCARD|P|2.3.1||||||<cr>
MSA|CA|090849JONES||||<cr>
MSH|^~\&|SPOCARD|EWHIN|JONES|EWHIN|199401010810||SRR^S01|0934849SPOCARD|P|2.3.1|||||||<cr>
MSA|AA|090849JONES||||<cr>
SCH|1994047^SCH001|1994567^SCH100|||||047^Referral|NORMAL|30|min|^^^199401060930^199401061000^^^^|0045^Jones^Harold^S^^^MD|555-4685|||087^Jensen^Helen^M^^^MD|555-9255||||BOOKED<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
RGS|001|<cr>
AIP|001|032^JENSEN^HELEN|002^CARDIOLOGIST|||||||NO|BOOKED<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>
MSH|^~\&|JONES|EWHIN|SPOCARD|EWHIN|199401010812||ACK|434532JONES|P|2.3.1||||||<cr>
MSA|CA|0934849SPOCARD||||<cr>
The
patient has asked Dr. Jensen to reschedule his January 6th appointment. Dr.
Jensen's scheduling application (the filler application) sends the PCP, Dr.
Jones, a notification that the original appointment has been rescheduled,
followed by a notification of the new appointment on January 9th at 1:00 PM.
MSH|^~\&|SPOCARD|EWHIN|JONES|EWHIN|199401040800||SIU^S13|021244SPOCARD|P|2.3.1|||AL|ER||<cr>
SCH|1994047^SCH001|1994567^SCH100|||||047^Referral|NORMAL|30|min|^^^199401091300^199401091330^^^^|0045^Jones^Harold^S^^^MD|555-4685|||087^Jensen^Helen^M^^^MD|555-9255||||BOOKED<cr>
NTE||The patient is going to be on vacation so cannot make previous
appointmentscheduled on January 6.<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
RGS|001|<cr>
AIP|001|032^JENSEN^HELEN|002^CARDIOLOGIST|||||||NO|BOOKED<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>
MSH|^~\&|JONES|EWHIN|SPOCARD|EWHIN|199401010802||ACK|035324JONES|P|2.3.1||||||<cr>
MSA|CA|021244SPOCARD||||<cr>
The
patient has been seen by his specialist, Dr. Smith, and requires treatment by a
physical therapist, Helen Morgan. Dr. Smith's office requests a one-hour
appointment each day for the next five days. Ms. Morgan's office responds to
the request with an appointment at 9:30 AM on June 20th through June 24th,
1994.
The patient has been seen by his specialist, Dr. Smith, and requires treatment
by a physical therapist, Helen Morgan. Dr. Smith's office requests a one-hour
appointment each day for the next five days. Ms. Morgan's office responds to
the request with an appointment at 9:30 AM on June 20th through June 24th,
1994.
MSH|^~\&|SMITH|EWHIN|MORGAN|EWHIN|199406190800||SRM^S01|03432SMITH|P|2.3.1|||AL|AL||<cr>
ARQ|19940347^SCH001|||||047^Referral||NORMAL|060|min|199406200930||Q1D|D5|00335^Smith^Harry^A^^^MD||||A3423^Jones^Fred||||<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport Highway^Mead^WA^99021||555-4685|||M||999-99-4413||||||||||<cr>
DG1|001|I9|833.00|Closed dislocation
wrist|199406190700|||||||||||||<cr>
RGS|001|<cr>
AIP|001|064^MORGAN^HELEN|097^PHYSICAL THERAPIST|||||||NO|<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|<cr>
MSH|^~\&|MORGAN|EWHIN|SMITH|EWHIN|199406190802||ACK|546644MORGAN|P|2.3.1||||||<cr>
MSA|CA|03432SMITH||||<cr>
MSH|^~\&|MORGAN|EWHIN|SMITH|EWHIN|199406190810||SRR^S01|0654544JONES|P|2.3.1||||||<cr>
MSA|AA|03432SMITH||||<cr>
SCH|1994037^SCH001|1994297^SCH100|||||047^Referral|NORMAL|60|min|^Q1D^D5^199406200930^199406240930^^^^|0335^Smith^Harry^A^^^MD||||064^Morgan^Helen|||||BOOKED<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
RGS|001|<cr>
AIP|001|064^MORGAN^HELEN|097^PHYSICAL THERAPIST|||||||NO|BOOKED<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>
MSH|^~\&|SMITH|EWHIN|MORGAN|EWHIN|199406190800||ACK|045742SMITH|P|2.3.1||||||<cr>
MSA|CA|0654544JONES||||<cr>
This chapter implies that the relationship of the repeating resource and service specific segments has a logical "and" relationship. In other words, if more than one AIP segment is sent in a transaction, it is logical to assume that both specified personnel resources are required for the appointment. Currently, there is no way to specify an "or" relationship between the resource and service segments. It is possible to specify a resource type and achieve a similar (but not equivalent) effect. See Section 10.8.1, "Logical relationship of resource and service segments" for a further discussion.
When
implementing the transactions defined in this chapter with multiple placer
applications, one must consider the implications of a situation when more than
one placer application asks to book, hold, lock, or otherwise reserve the same
slot or set of slots on a particular schedule.
This chapter makes no attempt to define attribute ownership (e.g., based on
application roles). Ownership is the right to create or update attribute
content. If two or more applications attempt simultaneously to update the same
attribute(s), deadly update collisions may occur, causing data corruption,
unless robust mechanisms for bidding and locking such attributes are in place
between applications. This chapter makes no attempt to address data ownership
issues or to define attribute bidding and locking mechanisms.
This chapter assumes that the placer and filler applications have put such
mechanisms into place, therefore resolving any contention or collision issues
at the application level. Further, if such mechanisms have not been
implemented by the applications, then this chapter assumes that procedural
solutions have been implemented by the healthcare provider organization to
resolve contention and collision issues.
An
implementor of a ballot draft specification of this chapter realized the need
to logically AND and OR multiple resources for a single appointment. For
example, they wished to specify the following condition:
((Resource-1 and Resource-2) or (Resource-3 and (Resource-4 or Resource-5)))
The current message structure for any kind of transaction does not address the
need for any of the service or resource detail segments (AIS, AIG, AIL, or
AIP).
They have proposed an extension to the Standard that would allow Lisp-like
logical syntax within messages such as the Schedule Request message. This
syntax makes use of a BEGIN and an END segment to logically group segments, and
an AND and an OR segment to logically connect segments. To achieve a request
as in the example above, the implementation of these logical grouping and
connecting segments would read as follows:
BEGIN|<cr>
BEGIN|<cr>
AIG|Resource-1...<cr>
AIG|Resource-2...<cr>
AND|<cr>
END|<cr>
BEGIN|<cr>
AIG|Resource-3...<cr>
BEGIN|<cr>
AIG|Resource-4...<cr>
AIG|Resource-5...<cr>
OR|<cr>
END|<cr>
AND|<cr>
END|<cr>
OR|<cr>
END|<cr>
This would translate to:
((Resource-1 Resource-2 AND) (Resource-3 (Resource-4 Resource-5 OR) AND)
OR)
This is the RPN or Lisp-like logical notation for the example in the first
paragraph. This syntax could encompass and support groupings of several
different resource and service types.
This proposal was presented to the Control/Query Technical Committee. Their
initial response was that this proposal is outside of the scope of
Control/Query for the current Standard 2.3 ballot and response cycle. If
necessary, this proposal will be resubmitted to the Control/Query Technical
Committee by the implementing organization for future versions of the Standard.
HL7 trigger events are not strictly limited to this definition; however, most trigger events do define state transitions.