The
header
for
a
message
exchange
that
is
either
requesting
or
responding
to
an
action.
The
resource(s)
that
are
the
subject
of
the
action
as
well
as
other
Information
related
to
the
action
are
typically
transmitted
in
a
bundle
in
which
the
MessageHeader
resource
instance
is
the
first
resource
in
the
bundle.
6.9.1
Scope
and
Usage
The
MessageHeader
resource
is
defined
in
order
to
support
Messaging
using
FHIR
resources
.
The
principle
usage
of
the
MessageHeader
resource
is
when
messages
are
exchanged.
However,
as
a
resource
that
can
be
used
with
the
RESTful
framework,
the
MessageHeader
resource
has
the
normal
resource
end-point
([base-url]/Message),
which
is
used
to
manage
a
set
of
static
messages
resources.
This
could
be
used
to
make
an
archive
of
past
messages
available.
Creating
or
updating
Message
resources
in
this
fashion
does
not
represent
the
actual
occurrence
of
any
event,
nor
can
it
trigger
any
logic
associated
with
the
actual
event.
It
is
just
for
managing
a
set
of
message
resources.
The
resources
referenced
by
the
enterer,
author
and
responsible
elements
may
all
be
included
in
the
message
bundle
or
left
out
on
the
basis
that
the
recipient
(and
any
intermediaries)
are
able
to
locate/resolve
the
resources
independently.
The
former
would
be
suitable
for
loosely
coupled
systems,
and
the
latter
for
tightly
coupled
systems.
The
messaging
conformance
statement
for
an
application
may
reference
a
profile
that
describes
how
the
bundling
occurs
The
actual
content
of
the
data
resource
is
specified
for
each
message
event
(see
the
list
on
the
messaging
page
).
Any
resources
referenced
in
the
data
element
are
always
included
in
the
bundle
If
MessageHeader.source.endpoint
and
MessageHeader.destination.endpoint
,
are
literal
URLs,
then
they
SHOULD
identify
the
addresses
to
which
messages
can
be
be
delivered.
If
they
are
logical
URIs
(i.e.
non-dereferenceable),
message
delivery
intermediaries
must
know
how
to
deliver
the
message
to
the
destination
application.
The
author
and
the
receiver
are
not
the
actual
technical
systems
-
these
are
the
human
or
organizations
that
make
use
of
the
technical
systems
A
receiver
is
not
obligated
to
reject
messages
which
do
not
explicitly
identify
it
as
receiver
(e.g.
a
tracker
will
get
messages
that
are
destined
for
some
other
system)
6.9.4
Search
Parameters
Search
parameters
for
this
resource.
The
standard
parameters
also
apply.
See
Searching
for
more
information
about
searching
in
REST,
messaging,
and
services.