This page is part of the FHIR Specification (v1.4.0:
STU
3 Ballot 3). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions 
The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR.
This includes two components:
A third component – defining standards for the sharing of common data element definitions between registries to enable broader and more consistent data element use is addressed in a second companion implementation guide .
This implementation guide is prepared as a U.S. Realm Specification on behalf of the Structured Data Capture project - an effort under the
U.S. Office of the National Coordinator (ONC) 
's
Standards
and
Infrastructure
(S
&
I)
Framework.
However,
much
of
the
content
is
likely
to
be
useable
in
other
jurisdictions.
The
only
portions
of
this
specification
that
may
be
problematic
for
use
of
this
implementation
guide
in
some
jurisdictions
are
the
bindings
to
terminologies
such
as
SNOMED
CT
and
RxNorm.
The
workflow,
constraints
and
extensions
used
should
all
have
broad
applicability.
's Standards and Infrastructure (S & I) Framework. However, much of the content is likely to be useable in other jurisdictions. The only portions of this specification that may be problematic for use of this implementation guide in some jurisdictions are the bindings to terminologies such as SNOMED CT and RxNorm. The workflow, constraints and extensions used should all have broad applicability.
This implementation guide follows the FHIR pattern of being published as a web-based specification. This allows easy navigation between the SDC-specific portion of the implementation guide and the resources, data types, value sets and other specification components leveraged from the FHIR core specification. This approach also allows implementers to easily navigate to the information needed to perform a particular task.
A Table of Contents page is provided that lists all of the pages and artifacts defined as part of this implementation guide. (Do be aware that some pages have multiple tabs.) A table of contents is also available for the full FHIR specification if you really want to read absolutely everything. Tooling may provide support for a PDF or other document-approach representation of this implementation guide in a future release.
Bread-crumb navigation is provided in the gray bar just below the menu at the top of each page, allowing easy navigation back to the main SDC page.
This implementation guide has a number of sections:
This implementation guide is based on the HL7
FHIR
data
types
Using
codes
References
between
resources
How
to
read
resource
&
profile
definitions
Base
resource
RESTful
operations
standard. It uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it's important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.
Feel free to explore other aspects of the FHIR specification that you feel may be relevant or of interest.
The following links provide additional context for the SDC specification.
The generic SDC workflow is pictured in Figure 1.
Figure 1: Generic Workflow
Note
:
The
diagram
depicts
the
optional
storage
of
the
completed
form
by
the
EHR.
This
can
occur
when
the
EHR
stores
a
copy
of
the
form
as
they
send
it
to
the
External
Data
Repository
or
by
the
external
data
repository
returning
a
copy
of
the
form
to
the
sender
who
can
store
an
internal
version
of
the
form.
: The diagram depicts the optional storage of the completed form by the EHR. This can occur when the EHR stores a copy of the form as they send it to the External Data Repository or by the external data repository returning a copy of the form to the sender who can store an internal version of the form.
The
fundamental
workflow
in
FHIR
is
to
complete
(and
potentially
submit)
a
completed
questionnaire
response.
The
driver
of
this
workflow
is
the
Form
Filler
system.
It
retrieves
a
form
(Questionnaire)
from
the
Form
Manager
.
It
may
also
request
that
the
Form
Manager
generate
an
initial
QuestionnaireResponse,
potentially
partially
populated
with
information
known
by
the
Form
Manager
or
supplied
by
the
Form
Filler.
The
Form
Filler
could
generate
the
QuestionnaireResponse
itself
without
the
assistance
of
the
Form
Manager
and
in
either
case
could
partially
fill
in
the
response
based
on
information
known
by
the
form
filler.
When
as
much
of
the
questionnaire
response
as
possible
has
been
filled
in
by
automated
means,
the
form
is
displayed
to
an
end-user
who
reviews
and
edits
the
automatically
populated
content
as
well
as
completing
those
portions
of
the
form
that
were
not
populated
automatically.
Finally,
the
form
filler
submits
the
form
to
one
or
more
target
repositories
(
The fundamental workflow in FHIR is to complete (and potentially submit) a completed questionnaire response. The driver of this workflow is the
Form Filler
system. It retrieves a form (Questionnaire) from the
Form Manager
. It may also request that the Form Manager generate an initial QuestionnaireResponse, potentially partially populated with information known by the Form Manager or supplied by the Form Filler. The Form Filler could generate the QuestionnaireResponse itself without the assistance of the Form Manager and in either case could partially fill in the response based on information known by the form filler. When as much of the questionnaire response as possible has been filled in by automated means, the form is displayed to an end-user who reviews and edits the automatically populated content as well as completing those portions of the form that were not populated automatically. Finally, the form filler submits the form to one or more target repositories (
Form
Receiver
allows
the
completed
form
to
be
subsequently
retrieved,
Form
Archiver
does
not)
and/or
stores
the
completed
form
itself.
The
pre-population
process
(done
by
the
Form
Manager)
and
the
auto-population
process
(done
by
the
Form
Filler
itself)
can
be
done
by
a
variety
of
means.
If
using
data
elements
referenced
directly
within
the
questionnaire
or
mapped
via
Form Receiver
allows the completed form to be subsequently retrieved,
Form Archiver
does not) and/or stores the completed form itself.
The pre-population process (done by the Form Manager) and the auto-population process (done by the Form Filler itself) can be done by a variety of means. If using data elements referenced directly within the questionnaire or mapped via
ConceptMap
,
those
may
need
to
be
retrieved
from
a
Data
Element
Registry
in
order
to
look
up
what
mappings
the
data
element
has
to
other
resources.
, those may need to be retrieved from a Data Element Registry
in order to look up what mappings the data element has to other resources.
The following sections describe the artifacts that set expectations for systems wishing to be conformant to the FHIR SDC implementation guide.
FHIR Conformance statements define the expectations for particular system "roles" within an SDC environment. To be considered SDC-conformant, a system must adhere to the requirements defined by at least one of these statements. Some systems might choose to comply with more than one.
In addition to the above, there's another relevant role:
When looking up data elements, the
SDC Form Designer
will communicate use of the
SDC Data Element Registry
, which is defined in the
SDC Data Element Exchange
implementation guide.
A summary of how these roles interact can be seen in Figure 2 and Figure 3 below:
Figure 2: Form Curation
Figure 3: Form Population
This implementation guide defines profiles on several resources. Implementations are expected to be conformant with these profiles in order to be conformant with this implementation guide.
Additional resources such as
Patient
,
,
Practitioner
,
,
Binary
,
,
ConceptMap
,
,
Provenance
,
,
AuditEvent
and
others
are
also
likely
to
be
used
in
SDC
solutions,
though
no
SDC-specific
profiles
have
been
created
for
them.
For
the
purposes
of
this
implementation
guide,
"must
support"
shall
be
interpreted
as
follows:
Conformant
systems
SHALL
be
capable
of
sending
and
receiving
the
data
element
When
a
system
persists
a
resource
instance,
all
"must
support"
elements
SHALL
be
persisted
and
retrieved
with
other
elements
Where
an
element
affects
the
display
or
validation
of
a
Questionnaire
and
a
system
performs
either
or
both
of
those
operations,
the
behavior
established
by
the
value
of
the
element
SHALL
be
performed
and others are also likely to be used in SDC solutions, though no SDC-specific profiles have been created for them.
For the purposes of this implementation guide, "must support" shall be interpreted as follows:
The
Questionnaire
resource
defines
a
custom
operation
called
resource defines a custom operation called
populate
.
This
operation
supports
generating
a
"blank"
. This operation supports generating a "blank"
QuestionnaireResponse
instance
based
on
a
specified
instance based on a specified
Questionnaire
.
It
also
allows
for
the
returned
questionnaire
to
be
partially
or
even
fully
completed
based
on
data
passed
in
to
the
operation
or
data
already
available
to
the
server
on
which
the
operation
is
invoked.
For
SDC
purposes,
server
systems
claiming
to
support
roles
that
require
support
for
the
. It also allows for the returned questionnaire to be partially or even fully completed based on data passed in to the operation or data already available to the server on which the operation is invoked.
For SDC purposes, server systems claiming to support roles that require support for the
populate
operation (
operation
(
SDC
Form
Manager
SDC Form Manager
)
SHALL,
at
minimum:
Handle
the
input
parameters
) SHALL, at minimum:
identifier
,
,
questionnaire
,
,
questionnaireRef
,
,
subject
and
and
content
content
Similarly, client systems claiming to support the
populate
operation (
operation
(
SDC
Form
Filler
SDC Form Filler
)
SHALL,
at
a
minimum:
Be
capable
of
invoking
the
operation
on
a
selected
questionnaire
both
directly
(
) SHALL, at a minimum:
Questionnaire/[identifier]/$populate
identifier
questionnaire
content
parameter
*
While
C-CDA
is
the
focus
for
compliance
with
this
release
of
the
SDC
specification,
systems
are
encouraged
to
support
additional
formats.
Candidates
for
mandatory
support
in
future
versions
of
this
implementation
guide
include
the
Clinical
Documents
for
Payers
-
SET
1
parameter
* While C-CDA is the focus for compliance with this release of the SDC specification, systems are encouraged to support additional formats. Candidates for mandatory support in future versions of this implementation guide include the
Clinical Documents for Payers - SET 1
(CPD1)
and
Physician
Reporting
to
a
Public
Health
Repository
(CPD1) and Physician Reporting to a Public Health Repository
specifications.
Systems
supporting
the
specifications.
Systems supporting the
populate
operation are encouraged to support using the
deReference
operation
are
encouraged
to
support
using
the
extension
to
trace
the
linkage
from
Questionniare
question
to
DataElement
to
support
mapping.
As
well,
systems
may
also
choose
to
support
the
use
of
the
extension to trace the linkage from Questionniare question to DataElement to support mapping. As well, systems may also choose to support the use of the
deMap
extension
to
support
maintaining
of
question
<->
data
element
links
outside
the
questionnaire
itself.
If
using
this
approach,
the
extension to support maintaining of question <-> data element links outside the questionnaire itself. If using this approach, the
ConceptMap
.
sourceUri
equal to the full resource id of the Questionnaire and a equal
to
the
full
resource
id
of
the
Questionnaire
and
a
targetUri
of the base URL for the DataElement end-point of the server to which data elements will be mapped. The of
the
base
URL
for
the
DataElement
end-point
of
the
server
to
which
data
elements
will
be
mapped.
The
ConceptMap.element.code
and and
ConceptMap.element.map.code
will correspond to the question linkId and the data element local id, respectively. Support for alternative mechanisms including ConceptMaps directly from Questionnaire questions to data sources, Questionnaire extensions providing mappings direct to data sources or use of Questionnaire.group.question.concept are all acceptable mechanisms for executing will
correspond
to
the
question
linkId
and
the
data
element
local
id,
respectively.
Support
for
alternative
mechanisms
including
ConceptMaps
directly
from
Questionnaire
questions
to
data
sources,
Questionnaire
extensions
providing
mappings
direct
to
data
sources
or
use
of
Questionnaire.group.question.concept
are
all
acceptable
mechanisms
for
executing
populate
functionality. functionality.
IMPORTANT:
Not
all
Not all
DataElements
will
be
appropriate
or
safe
to
reference
in
a
Questionnaire.
It
is
important
that
the
definition
associated
with
the
data
element
fully
reflects
the
context
of
the
question
in
the
questionnaire.
For
example,
"gender"
would
not
be
a
safe
data
element
because
it
would
not
be
clear
whether
the
gender
was
that
of
the
patient
or
a
fetus
of
the
patient.
It
must
be
clear
from
the
data
element
definition
exactly
what
piece
of
information
should
be
extracted
from
a
source
system,
C-CDA
document
or
other
data
source.
Mapping
to
C-CDA,
where
applicable,
should
be
constrained
and
specific
(e.g.
for
particular
demographic
sections)
rather
than
making
it
open
and
generic.
These
mappings
should
be
per
ONC's
recommendations.
Mapping
to
C-CDA
is
one
of
many
options,
not
the
only
one.
will be appropriate or safe to reference in a Questionnaire. It is important that the definition associated with the data element fully reflects the context of the question in the questionnaire. For example, "gender" would not be a safe data element because it would not be clear whether the gender was that of the patient or a fetus of the patient. It must be clear from the data element definition exactly what piece of information should be extracted from a source system, C-CDA document or other data source.
Mapping to C-CDA, where applicable, should be constrained and specific (e.g. for particular demographic sections) rather than making it open and generic. These mappings should be per ONC's recommendations. Mapping to C-CDA is one of many options, not the only one.
While this implementation guide and the underlying FHIR are licensed as public domain, this guide mandates the use of terminologies including LOINC, SNOMED CT and RxNorm which have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and any other constraints of terminologies, questionnaires, data elements and other components used as part of their implementation process. In some cases, licensing requirements may limit what systems data captured using this implementation guide may be shared with.
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100.
QA Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Compare
to
DSTU1
|
Version History
|
Table of Contents
|
Compare to DSTU2
|
|
|
Propose
a
change
|
Propose a change