This
page
is
part
of
the
FHIR
Specification
(v0.0.82:
(v1.0.2:
DSTU
1).
2).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
1.6
Open
Outstanding
Issues
There
are
a
number
of
issues
in
which
input
based
on
implementation
experience
This
specification
is
specifically
sought
during
the
currently
in
its
second
round
of
trial
use
phase:
use.
Much
work
remains
to
be
done.
Conformance
:
How
system
profiles
Specifically,
there
are
used
still
many
outstanding
questions
about
the
Request/Fulfillment
cycle
(
Order
:
The
need
for
additional
kinds
of
order
to
be
defined
Resource
Identification
:
Managing
resource
identification
in
distributed
systems
Query
/
Search
:
How
should
text
search
be
standardized?
Query
/
Search
:
How
much
should
_include
be
standardized?
Security
Labels
:
How
much
policy
can
be
standardized,
OrderResponse
and
how
does
this
impact
on
this
specification?
Security
:
What
use
cases
are
there
for
digital
signatures?
Messaging
:
Messaging
has
not
yet
been
well-exercised
at
connectathon,
so
feedback
based
on
implementation
various
statuses
and
workflows
associated
with
requests,
as
well
as
how
proposals
cascade
to
plans
to
orders
to
downstream/encoded
orders,
etc.
This
is
welcome
a
matter
of
ongoing
investigation.
In
addition,
there
are
the
following
general
areas
of
functionality
have
been
deferred
to
a
future
proposed
resources:
version:
-
A
notification
resource
for
creating
and
recording
notifications
between
parties
Adverse
Event
Reporting
-
An
alarm
resource
to
represent
current
issues
with
the
patient
(e.g.
device
created)
-
A
person
resource
to
support
person
registries
Concern
Tracking
-
An
appointment
resource
for
making
Clinical
Studies
and
tracking
arrangements
around
the
future
of
care
Protocols
-
Aggregated
Data
Reporting
including
Public
Health
Reporting
-
Payment
related
resources,
and
specifically,
an
Account
resource
for
payment
tracking
-
Possibly
a
way
to
define
particular
queries
(finer
detail
than
Profile
provides)
One
or
more
resources
for
Advance
Care
Directive
/
Power
of
Attorney
-
Use
of
RDF
-
A
full
server
side
query
framework
Note
that
other
resources
beyond
these
may
be
anticipated.
For
some
of
these,
some
draft
content
is
included
in
the
specification
for
implementer
consideration.
In
addition
addition,
there
are
a
number
of
specific
notes
in
the
specification
requesting
feedback
from
implementers:
-
AllergyIntolerance
:
how
to
these,
further
work
report
'no
known
allergies'
of
various
flavors
-
Appointment
:
suitability
of
Appointment.priority
values
-
BodySite
:
suitability
of
this
as
a
resource?
-
CarePlan
:
2
questions
about
usage
-
ClinicalImpression
:
general
usage
questions
-
Composition
:
question
about
title
being
mandatory,
and
about
signatures
-
Invariants
:
is
planned
around
tracking
there
a
replaceement
for
XPath?
-
DataElement
:
question
about
relationship
between
DataElement
and
reporting
clinical
observations
/
vital
signs,
other
resources
-
Markdown
:
which
markdown
flavor
can
we
settle
on,
if
any?
-
DiagnosticReport
:
relationship
with
Observation
-
RESTful
API
:
question
about
using
the
PATCH
operation
-
RESTful
API
:
what
should
we
do
about
side-effects
and
supporting
remote
consultations
/
telehealth.
transactions?
-
RESTful
API
:
Transaction
integrity
and
introspection
-
Resource
Identification
:
identifier
policy
rules?
-
Messaging
:
what
additional
events
should
be
defined?
-
Operations
:
should
it
be
possible
to
execute
operations
asynchronously?
-
Patient
:
what
effect
linking/merging/unlinking
should
have
on
other
functionality
such
as
the
GET
operation?
-
Patient
:
Comment
on
MPI
search
query
sought
-
Profiling
:
Note
about
need
for
feedback
about
use
of
profiles
-
References
:
Should
inside
out
containment
be
allowed?
-
RiskAssessment
:
General
usage
questions
-
Search
:
how
much
should
text
search
be
standardised?
-
Search
:
Should
additional
rules
about
how
_include
works
be
made?
-
Security
:
Using
signatures
with
RESTful
interfaces
is
a
poorly
understood
area
-
Subscription
:
Use
with
messaging
is
still
to
be
clarified