This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
(v3.3.0:
R4
Ballot
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
| FHIR Infrastructure Work Group | Maturity Level : N/A | Ballot Status : Informative | Compartments : Not linked to any defined compartments |
This is the narrative for the resource. See also the XML or JSON format.
OPERATION: Generate HTML for Questionnaire
The official URL for this operation definition is:
http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml
Generates
an
HTML
page
as
a
Binary
instance
based
on
a
specified
Questionnaire
,
filling
in
answers
to
questions
where
possible
based
on
information
provided
as
part
of
the
operation
or
already
known
by
the
server
about
the
subject
of
the
Questionnaire
.
If
the
operation
is
not
called
at
the
instance
level,
one
and
only
one
of
the
identifier,
questionnaire
or
questionnaireRef
'in'
parameters
must
be
provided.
If
called
at
the
instance
level,
these
parameters
will
be
ignored.
The
response
will
contain
a
Binary
instance
containing
an
HTML
page
for
filling
in
and
submitting
the
specified
Questionnaire
and/or
an
OperationOutcome
resource
with
errors
or
warnings.
The
generated
HTML
form
instance
will
be
populated
with
an
unanswered
set
of
questions
following
the
group
and
question
structure
of
the
specified
Questionnaire
.
If
content
parameters
were
specified
or
the
local
parameter
was
set
to
true,
some
of
the
questions
may
have
answers
filled
in
as
well.
In
the
case
of
repeating
questions
or
groups,
typically
only
one
repetition
will
be
provided
unless
answer
values
exist
that
would
support
populating
multiple
repetitions.
Population
of
the
HTML
form
with
appropriate
data
is
dependent
on
the
questions
and/or
groups
in
the
Questionnaire
having
metadata
that
allows
the
server
to
recognize
the
questions,
e.g.
through
Questionnaire.item.definition
or
through
use
of
the
ConceptMap
resource.
Regardless
of
the
mechanism
used
to
link
the
questions
in
a
questionnaire
to
a
"known"
"known"
mappable
concept,
solutions
using
this
operation
should
ensure
that
the
details
of
the
question
and
associated
linkage
element
are
sufficiently
similar
as
to
safely
allow
auto-population;
i.e.
the
question
text
and
context
must
be
sufficiently
the
same,
the
value
set
for
the
question
must
fall
within
the
value
set
for
the
mapped
element,
the
data
types
must
be
the
same
or
convertible,
etc.
URL: [base]/Questionnaire/$populatehtml
URL: [base]/Questionnaire/[id]/$populatehtml
Parameters
| Use | Name | Cardinality | Type | Binding | Documentation |
| IN | identifier | 0..1 | uri |
A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories. |
|
| IN | questionnaire | 0..1 | Questionnaire |
The Questionnaire is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion |
|
| IN | questionnaireRef | 0..1 | Reference |
The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire. |
|
| IN | content | 0..* | Reference |
Resources
containing
information
to
be
used
to
help
populate
the
generated
HTML
form.
These
may
be
FHIR
resources
or
may
be
binaries
containing
FHIR
documents,
CDA
documents
or
other
source
materials.
Servers
|
|
| IN | local | 0..1 | boolean |
If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions. |
|
| OUT | form | 1..1 | Binary |
The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire |
|
| OUT | issues | 0..1 | OperationOutcome |
A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter |
While
it
is
theoretically
possible
for
an
HTML
form
to
be
completely
auto-populated
and
submitted
without
human
review,
the
intention
of
this
transaction
is
merely
to
reduce
redundant
data
entry.
The
HTML
form
SHOULD
ensure
that
a
human
submitter
has
an
opportunity
to
review
the
auto-populated
answers
to
confirm
correctness
as
well
as
to
complete
or
expand
on
information
provided
by
the
auto-population
process.
Complex
form
designs
with
conditional
logic
or
tight
constraints
on
cardinalities
may
be
challenging
to
auto-populate.
A
server
MAY
choose
to
traverse
the
questionnaire
as
if
it
were
a
human
respondent,
answering
only
those
questions
that
are
enabled
based
on
previously
answered
questions.
However,
doing
so
may
result
in
minimal
population.
Alternatively,
systems
may
choose
to
populate
all
known
answers,
independent
of
dependencies
and
other
constraints.
This
may
cause
questions
to
be
answered
that
should
not
be
answered.
The
generated
HTML
form
is
responsible
for
pruning
the
final
populated
questionnaire
once
human
review
has
taken
place.
Invoking
this
operation
with
the
''content''
parameter
may
involve
the
disclosure
of
personally
identifiable
healthcare
information
to
the
system
which
is
performing
the
population
process.
No
such
disclosures
should
be
made
unless
the
system
on
which
the
operation
is
being
invoked
is
a
"trusted"
"trusted"
system
and
appropriate
agreements
are
in
place
to
protect
the
confidentiality
of
any
information
shared
with
that
system.
Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.