Conformance
This page is part of the FHIR Specification (v1.6.0:
STU
3 Ballot 4). 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 
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
|
|
|
|
The base FHIR specification (this specification) describes a set of base resources, frameworks and APIs that are used in many different contexts in healthcare. However there is wide variability between jurisdictions and across the healthcare ecosystem around practices, requirements, regulations, education and what actions are feasible and/or beneficial.
For this reason, the FHIR specification is a "platform specification" - it creates a common platform or foundation on which a variety of different solutions are implemented. As a consequence, this specification usually requires further adaptation to particular contexts of use. Typically, these adaptations specify:
Note that because of the nature of the healthcare ecosystem, there may be multiple overlapping sets of adaptations - by healthcare domain, by country, by institution, and/or by vendor/implementation.
FHIR defines a cascade of artifacts for this purpose:
| Artifact | Description |
example
|
| Implementation Guide (IG) | A coherent and bounded set of adaptations that are published as a single unit. Validation occurs within the context of the Implementation Guide |
DAF IG
|
|
Package
| A group of related adaptations that are published as a group within an Implementation Guide |
DAF Medication Usage
|
| Conformance Resource | A single resource in a package that makes rules about how an implementation works. These are described below |
|
The term "profile" is a general one that is used about either a "package" or an "item". "Profiling" is a general term that describes the process of creating an implementation guide, or any of the conformance resources found in one.
Typically, Implementation Guides both restrict and extend APIs, resources and terminologies. FHIR provides a set of resources that can be used to represent and share the decisions that have been made, and allows implementers to build useful services from them. These resources are known as the conformance resources. These conformance resources allow implementers to:
These resources need to be used as discussed below, and also following the basic concepts for extension that are described in
"Extensibility"
.
For
implementer
convenience,
the
specification
itself
publishes
its
base
definitions
using
these
same
resources.
. For implementer convenience, the specification itself publishes its base definitions using these same resources.
The
Conformance
resource
describes
two
different
uses
for
profiles
on
resources:
Resource
Profiles
and
System
Profiles.
Resource
Profiles
are
specified
using
the
resource describes two different uses for profiles on resources: Resource Profiles and System Profiles. Resource Profiles are specified using the
Conformance.rest.resource.profile
element
and
System
Profiles
are
specified
using
the
element and System Profiles are specified using the
Conformance.profile
element.
element.
These profiles describe the general features that are supported by the system for each kind of resource. Typically, this is the superset of all the different use-cases implemented by the system. This is a resource-level perspective of a system's functionality.
These profiles describe the information handled/produced by the system on a per use case basis. Some examples of the uses for these kind of profiles:
Typically, these profiles are a series of variations on the same set of resources - different use cases leading to handling the resources that represent them differently. These usecases described above all pertain to system that produce and publish data, but the same concept applies to systems that consume data. For instance:
For producer and a consumer systems to exchange data successfully based on one of these system supported profiles, it's not enough to know that the systems happen to have system profiles that overlap for the use case of interest; the consumer must be able to filter the total set of resources made available by the producer system and deal only with the ones relevant to the use case.
As an example consider a laboratory system generating thousands of reports a day. 1% of those reports are a particular endocrine report that a decision support system knows how to process. Both systems declare that they support the particular endocrine report profile, but how does the expert system actually find the endocrine reports that it knows how to process?
One possible option is for the expert system to receive every single report coming from the lab system, check whether it conforms to the profile or not, and then decide whether to process it. Checking whether a resource conforms to a particular profile or not is a straight forward operation (one option is to use the
provided tools for this
),
but
this
is
very
inefficient
way
-
the
expert
system
has
to
receive
and
process
100
times
many
resources
as
it
uses.
To
help
a
consumer
find
the
correct
set
of
reports
for
a
use-case,
a
producer
of
resources
also
SHALL,
for
any
profile
declared
in
Conformance.profile:
), but this is very inefficient way - the expert system has to receive and process 100 times many resources as it uses. To help a consumer find the correct set of reports for a use-case, a producer of resources also SHALL, for any profile declared in Conformance.profile:
Beyond these requirements, a producer of resources SHOULD ensure that any resource instance that would reasonably be expected to conform to the declared profiles SHOULD be published in this form.
DSTU Note: there are many uninvestigated issues associated with this use of profiles. HL7 is actively seeking feedback from users who experiment in this area, and users should be prepared for changes to features and obligations in this area in the future.
Feedback here
..
A conformance resource lists the REST interactions (read, update, search, etc.) that a server provides or that a client uses, along with some supporting information for each. It can also be used to define a set of desired behavior (e.g. as part of a specification or a Request for Proposal). The only interaction that servers are required to support is the
Conformance
resource
supports
defining
what
OperationDefinitions
make
use
of
particular
names
on
an
end-point.
If
services
are
defined
that
are
not
declared
using
OperationDefinition,
it
may
be
appropriate
to
use
longer
names,
reducing
the
chance
of
collision
(and
confusion)
with
services
declared
by
other
interfaces.
The
base
specification
will
never
define
operation
names
with
a
"."
in
them,
so
implementers
are
recommended
to
use
some
appropriate
prefix
for
their
names
(such
as
"ihe.someService")
to
reduce
the
likelihood
of
name
conflicts.
Implementations
are
encouraged,
but
not
required,
to
define
operations
using
the
standard
FHIR
operations
framework
-
that
is,
to
declare
the
operations
using
the
OperationDefinition
resource,
but
some
operations
may
involve
formats
that
can't
be
described
that
way.
Implementations
are
also
able
to
extend
the
FHIR
API
using
additional
content
types.
For
instance,
it
might
be
useful
to
interaction itself - to retrieve the server's conformance statement. Beyond that, servers and clients support and use whichever API calls are relevant to their use case.
In addition to the operations that FHIR provides, servers may provide additional operations that are not part of the FHIR specification. Implementers can safely do this by appending a custom operation name prefixed with '$' to an existing FHIR URL, as the Operations framework does. The Conformance resource supports defining what OperationDefinitions make use of particular names on an end-point. If services are defined that are not declared using OperationDefinition, it may be appropriate to use longer names, reducing the chance of collision (and confusion) with services declared by other interfaces. The base specification will never define operation names with a "." in them, so implementers are recommended to use some appropriate prefix for their names (such as "ihe.someService") to reduce the likelihood of name conflicts.
Implementations are encouraged, but not required, to define operations using the standard FHIR operations framework - that is, to declare the operations using the OperationDefinition resource, but some operations may involve formats that can't be described that way.
Implementations are also able to extend the FHIR API using additional content types. For instance, it might be useful to
read
or
or
update
the
appointment
resources
using
a
vCard
based
format.
vCard
defines
its
own
mime
type,
and
these
additional
mime
types
can
safely
be
used
in
addition
to
those
defined
in
this
specification.
the appointment resources using a vCard based format. vCard defines its own mime type, and these additional mime types can safely be used in addition to those defined in this specification.
Extending and restricting resources (collectively known as 'profiling a resource') is done with a "StructureDefinition" resource, which is a statement of rules about how the elements in a resource are used, and where extensions are used in a resource.
One key function of profiles is to change the cardinality of an element. A profile can restrict the cardinality of an element within the limits of the base structure it is constraining. This table summarizes what types of restrictions are allowed:
|
|
0..0
|
0..1
(optional) |
0..n
|
1..1
(required) |
1..n
|
| 0..1 | yes | yes | no | yes | no |
| 0..* | yes | yes | yes | yes | yes |
| 1..1 | no | no | no | yes | no |
| 1..* | no | no | no | yes |
yes
|
When a profile is constraining another profile where there are more cardinality options (e.g. low is not just 0 or 1, and high is not just 1 or *), the same principles still apply: the constraining profile can only allow what the base profile allows.
What Structure Definitions can do when they are constraining existing resources and datatypes is limited in some respects:
The consequence of this is that if a profile mandates extended behavior that cannot be ignored, it must also mandate the use of a modifier extension . Another way of saying this is that knowledge must be explicit in the instance, not implicit in the profile.
As an example, if a profile wished to describe that a
Procedure
resource
was
being
negated
(e.g.
asserting
that
it
never
happened),
it
could
not
simply
say
in
the
profile
itself
that
this
is
what
the
resource
means;
instead,
the
profile
must
say
that
the
resource
must
have
an
extension
that
represents
this
knowledge.
There
is
a
facility
to
mark
resources
to
indicate
that
they
can
only
be
safely
understood
by
a
process
that
is
aware
of
and
understands
a
set
of
published
rules.
For
more
information,
see
Restricted
Understanding
of
Resources
.
resource was being negated (e.g. asserting that it never happened), it could not simply say in the profile itself that this is what the resource means; instead, the profile must say that the resource must have an extension that represents this knowledge.
There is a facility to mark resources to indicate that they can only be safely understood by a process that is aware of and understands a set of published rules. For more information, see Restricted Understanding of Resources .
A "constraint" Structure Definition specifies a set of restrictions on the content of a FHIR resource or data type, or an additional set of constraints on an existing profile. A given structure definition is identified by its canonical URL, which SHOULD be the URL at which it is published. The following kinds of statements can be made about how an element is used, using a series of Element Definitions :
Any changed definitions SHALL be restrictions that are consistent with the rules defined in the resource in the FHIR Specification from which the profile is derived. Note that some of these restrictions can be enforced by tooling (and are by the FHIR tooling), but others (e.g. alignment of changes to descriptive text) cannot be automatically enforced.
Note that structure definitions cannot 'remove' mappings and constraints that are defined in the base structure, but for purposes of clarity, they can refrain from repeating them.
A structure definition contains a linear list of
element definitions
. The inherent nested structure of the elements is derived from the
path
value
of
each
element.
For
instance,
a
sequence
of
the
element
paths
like
this:
value of each element. For instance, a sequence of the element paths like this:
defines the following structure:
<Root> <childA><grandChild/><grandChild1/> </childA> <childB/> </Root>or its JSON equivalent. The structure is coherent - children are never implied, and the path statements are always in order. The element list is a linear list rather than being explicitly nested because element definitions are frequently re-used in multiple places within a single definition, and this re-use is easier with a flat structure.
or its JSON equivalent. The structure is coherent - children are never implied, and the path statements are always in order. The element list is a linear list rather than being explicitly nested because element definitions are frequently re-used in multiple places within a single definition, and this re-use is easier with a flat structure.
Structure Definitions may contain a differential statement, a snapshot statement or both.
Differential statements describe only the differences that they make relative to another structure definition (which is most often the base FHIR resource or data type). For example, a profile may make a single element mandatory (cardinality 1..1). In the case of a differential structure, it will contain a single element with the path of the element being made mandatory, and a cardinality statement. Nothing else is stated - all the rest of the structural information is implied (note: this means that a differential profile can be sparse and only mention the elements that are changed, without having to list the full structure. This rule includes the root element - it is not needed in a sparse differential).
Note that a differential can choose not to constrain elements. Doing so means that the profile will be more flexible in terms of compatibility with other profiles, but will require more work to support from implementing systems. Alternatively, a profile can constrain all optional elements to be not present (max cardinality = 0) - this closes the content, which makes implementation easier, but also reduces its usefulness.
In order to properly understand a differential structure, it must be applied to the structure definition on which it is based. In order to save tools from needing to support this operation (which is computationally intensive - and impossible if the base structure is not available), a StructureDefinition can also carry a "snapshot" - a fully calculated form of the structure that is not dependent on any other structure. The FHIR project provides tools for the common platforms that can populate a snapshot from a differential (note that the tools generate complete verbose snapshots; they do not support suppressing mappings or constraints).
StructureDefinitions can contain both a differential and a snapshot view. In fact, this is the most useful form - the differential form serves the authoring process, while the snapshot serves the implementation tooling. StructureDefinition resources used in operational systems should always have the snapshot view populated.
One common feature of constraining Structure Definitions is to take an element that may occur more than once (e.g. in a list), and split the list into a series of sublists, each with different restrictions on the elements in the sublist with associated additional meaning. In FHIR, this operation is known as "Slicing" a list. It is common to "slice" a list into sub-lists each containing just one element, effectively putting constraints on each element in the list. This technique can also be used on elements that do not repeat, but that have a choice of data types.
Here is an example to illustrate the process:
In this example, the base structure definition for the resource
Observation
defines
the
"component"
element
which
contains
a
nested
code
and
a
value
for
observations
that
have
multiple
values.
A
classic
example
of
this
kind
of
observation
is
a
blood
pressure
measurement
-
it
contains
2
values,
one
for
systolic,
and
one
for
diastolic
(
defines the "component" element which contains a nested code and a value for observations that have multiple values. A classic example of this kind of observation is a blood pressure measurement - it contains 2 values, one for systolic, and one for diastolic (
example
).
This
diagram
shows
the
conceptual
process
of
'slicing'
the
component
list
into
systolic
and
diastolic
slices
(note:
to
avoid
clutter,
the
"name"
attribute
of
Observation
is
shown
as
just
a
code
not
a
full
CodeableConcept).
The
structure
definition
for
Blood
Pressure
splits
the
component
list
into
two
sublists
of
one
element
each:
a
systolic
element,
and
a
diastolic
element.
Each
of
these
elements
has
a
fixed
value
for
the
code
element
(a
fixed
LOINC
code
for
the
name),
and
both
have
a
value
of
type
Quantity.
This
process
is
known
as
"slicing"
and
the
Systolic
and
Diastolic
elements
are
called
"slices".
Note
that
when
the
resource
is
exchanged,
the
wire
format
that
is
exchanged
is
not
altered
by
the
constraining
definition.
This
means
that
the
item
profile
names
defined
in
the
structure
definition
("systolic",
etc.
in
this
example)
are
never
exchanged.
A
resource
instance
looks
like
this:
).
This diagram shows the conceptual process of 'slicing' the component list into systolic and diastolic slices (note: to avoid clutter, the "name" attribute of Observation is shown as just a code not a full CodeableConcept).
The structure definition for Blood Pressure splits the component list into two sublists of one element each: a systolic element, and a diastolic element. Each of these elements has a fixed value for the code element (a fixed LOINC code for the name), and both have a value of type Quantity. This process is known as "slicing" and the Systolic and Diastolic elements are called "slices".
Note that when the resource is exchanged, the wire format that is exchanged is not altered by the constraining definition. This means that the item profile names defined in the structure definition ("systolic", etc. in this example) are never exchanged. A resource instance looks like this:
<Observation> ... <component><code {LOINC="8480-6}"/><code {LOINC="8480-6"}/> <value ...> </component> <component><code {LOINC="8462-4}"/><code {LOINC="8462-4"}/> <value ...> </component> </Observation>In order to determine that the first related item corresponds to "Systolic" in the structure definition, so that it can determine to which additional constraints for a sub-list the item conforms, the system checks the values of the elements. In this case, the "name" element in the target resource can be used to determine which slice that target refers to. This element is called the "discriminator".
In order to determine that the first related item corresponds to "Systolic" in the structure definition, so that it can determine to which additional constraints for a sub-list the item conforms, the system checks the values of the elements. In this case, the "code" element in the target resource can be used to determine which slice that target refers to. This element is called the "discriminator".
In the general case, systems processing resources using a structure definition that slices a list can determine the slice corresponding to an item in the list by checking whether the item's content meets the rules specified for the slice. This would require a processor to be able to check all the rules applied in the slice and to do so speculatively in a depth-first fashion. Both of these requirements are inappropriately difficult for an operational system, and particularly for generated code (e.g. software that is automatically produced based on the StructureDefinition). Thus, to provide a better way to distinguish slices, a sliced element can designate a field or set of fields that act as a "discriminator" - they are used to tell the slices apart.
When a discriminator is provided, the composite of the values of the elements designated in the discriminator is unique and distinct for each possible slice and applications can easily determine which slice an item in a list is. The intention is that this can be done in generated code, e.g. using a switch/case statement. When slicing elements with a choice of types, the discriminator SHALL be "@type".
When a constraining structure designates one or more discriminators, it SHALL fix the value of the element for each discriminator for each slice (using
ElementDefinition.fixed[x]
),
or
if
the
element
has
a
terminology
binding,
it
SHALL
be
associated
with
a
complete
binding
with
a
required
Value
Set
that
enumerates
the
list
of
possible
codes
in
the
value
set.
The
structure
definition
SHALL
ensure
that
there
is
no
overlap
between
the
set
of
values
and/or
codes
in
the
value
sets
between
slices.
Note:
At
present,
only
a
fixed
value
or
a
required
value
set
should
be
used
for
slicing;
using
), or if the element has a terminology binding, it SHALL be associated with a required binding with a
Value Set
that enumerates the list of possible codes in the value set. The structure definition SHALL ensure that there is no overlap between the set of values and/or codes in the value sets between slices. Note: At present, only a fixed value or a required value set should be used for slicing; using
ElementDefinition.pattern[x]
)
is
not
recommended
as
a
basis
for
slicing
while
issues
related
to
this
are
investigated
during
the
DSTU
period.
It
is
the
composite
(combined)
values
of
the
discriminators
that
are
unique,
not
each
discriminator
alone.
For
example,
a
slice
on
a
list
of
items
that
are
references
to
other
resources
could
designate
fields
from
different
resources,
where
each
resource
only
has
one
of
the
designated
elements,
as
long
as
they
are
distinct
across
slices.
A
structure
definition
is
not
required
to
designate
any
discriminator
at
all
for
a
slice,
but
those
that
don't
identify
discriminators
are
describing
content
that
is
very
difficult
to
process,
and
so
this
is
discouraged.
Within
a
structure
definition,
a
slice
is
defined
using
multiple
is not recommended as a basis for slicing while issues related to this are investigated during the DSTU period.
It is the composite (combined) values of the discriminators that are unique, not each discriminator alone. For example, a slice on a list of items that are references to other resources could designate fields from different resources, where each resource only has one of the designated elements, as long as they are distinct across slices.
A structure definition is not required to designate any discriminator at all for a slice, but those that don't identify discriminators are describing content that is very difficult to process, and so this is discouraged.
Within a structure definition, a slice is defined using multiple
element
entries
that
share
a
entries that share a
path
but
have
distinct
but have distinct
name
s.
These
entries
together
form
a
"slice
group"
that
is:
s. These entries together form a "slice group" that is:
The value of the discriminator element is a path name that identifies the descendant element using a dotted notation. For references, the path transitions smoothly across the reference and into the children of the root element/object of the resource. For extensions, an extension can be qualified with the URL of the extensions being referred to. There are two special names: @type, and @profile. Here are some example discriminators:
| Context | Discriminator | Interpretation |
| List.entry |
item.reference.name
| Entries are differentiated by the name element on the target resource - probably an observation, which could be determined by other information in the profile |
| List.entry |
item.reference.@type
| Entries are differentiated by the type of the target element that the reference points to |
| List.entry |
item.reference.@profile
| Entries are differentiated by a profile tag on the target of the reference, as specified by a structure definition (todo: how to do that?) |
|
List.entry
| item.extension("http://acme.org/extensions/test").code | Entries are differentiated by the value of the code element in the extension with the designated URL |
|
List.entry.extension
|
url
| Extensions are differentiated by the value of their url property (usually how extensions are sliced) |
|
List.entry
| item.reference.@type, item.reference.code | Extensions are differentiated by the combination of the type of the referenced resource, and, if it has one, the code element of that resource. This would be appropriate for where a List might be composed of a Condition, and set of observations, each differentiated by its name - the condition has no name, so that is evaluated as a null in the discriminator set |
| Observation.value[x] |
@type
| Different constraints (e.g. "must support", usage notes, vocabulary bindings, etc.) are asserted for different supported types for the multi-typed element Observation.value[x] |
Note that @type and @profile can also be used where a repeating element contains a resource directly (e.g. DomainResource.contained , Bundle.entry , Parameters.parameter.resource ).
The examples of slicing and discriminators show exactly how this and other typical uses of slicing are represented in profiles.
When creating a profile based on another profile, it's sometimes necessary to slice data that has already been sliced in the base profile. This is called "Re-slicing". The rules for re-slicing are as follows:
When you slice, you define a name for each new slice. The name has to be unique across the set of slices in the profile. So if profile A defines an element X with cardinality 0..*, and profile B is derived from profile A, then profile B can either:
Then, profile C derives from profile B. Profile C can do the following:
Note: it is possible for Profile C to make rules that are incompatible with profile B, in which case there is no set of instances that can be valid against profile C
In addition to the above, there are times when Profile C will need to further slice a slice defined in B. In this case, there's a need to reference both the name of the original slice from Profile B as well as to define a name for the slice defined within Profile C. This is done by separating the names using "/". For example, if Profile B defines the slice "example", and profile C defines the slice "example/example1", then this is deemed to be "example1" slice of the example slice. This process can continue indefinitely by separating each layer of slicing names with the "/" character.
An extension definition defines the URL that identifies the extension and which is used to refer to the extension definition when it is used in a resource.
The extension definition also defines the context where the extension can be used (usually a particular path or a data type) and then defines the extension element using the same details used to profile the structural elements that are part of resources. This means that a single extension can be defined once and used on different Resource and/or datatypes, e.g. one would only have to define an extension for "hair color" once, and then specify that it can be used on both Patient and Practitioner.
For further discussion of defining and using extensions, along with some examples, see
Extensibility
.
.
Once defined, an extension can be used in an instance of a resource without any Profile declaring that it can, should or must be, but Profiles can be used to describe how an extension is used.
To actually prescribe the use of an extension in an instance, the extension list on the resource needs to be sliced. This is shown in
the extensibility examples
Note
that
the
minimum
cardinality
of
an
extension
SHALL
be
a
valid
restriction
on
the
minimum
cardinality
in
the
definition
of
the
extension.
if
the
minimum
cardinality
of
the
extension
is
1
when
it
is
defined,
it
can
only
be
mandatory
when
it
is
added
to
a
profile.
This
is
not
recommended
-
the
minimum
cardinality
of
an
extension
should
usually
be
0.
Note that the minimum cardinality of an extension SHALL be a valid restriction on the minimum cardinality in the definition of the extension. if the minimum cardinality of the extension is 1 when it is defined, it can only be mandatory when it is added to a profile. This is not recommended - the minimum cardinality of an extension should usually be 0.
Coded elements have bindings that link from the element to a definition of the set of possible codes the element may contain. The binding identifies the definition of the set of possible codes and controls how tightly the set of the possible codes is interpreted.
The set of possible codes is either a formal reference to a
ValueSet
resource,
which
may
be
version
specific,
or
a
general
reference
to
some
web
content
that
defines
a
set
of
codes.
The
second
is
most
appropriate
where
a
set
of
values
is
defined
by
some
external
standard
(such
as
mime
types).
Alternatively,
where
the
binding
is
incomplete
(e.g.
under
development)
just
a
text
description
of
the
possible
codes
can
be
provided.
Bindings
have
a
property
that
defines
how
the
strongly
implementations
are
required
to
use
the
set
of
codes.
See
Binding
Strength
.
resource, which may be version specific, or a general reference to some web content that defines a set of codes. The second is most appropriate where a set of values is defined by some external standard (such as mime types). Alternatively, where the binding is incomplete (e.g. under development) just a text description of the possible codes can be provided.
Bindings have a property that defines how the strongly implementations are required to use the set of codes. See Binding Strength .
CodeSystem
resources can be used to carry definitions of local codes (
Example
)
and
to
mix
a
combination
of
local
codes
and
standard
codes
(e.g.
LOINC,
SNOMED),
or
just
to
choose
a
particular
set
of
standard
codes
(examples:
LOINC,
SNOMED,
RxNorm).
Profiles
can
bind
to
these
value
sets
instead
of
the
ones
defined
in
the
base
specification,
following
these
rules:
) and
ValueSets
can mix a combination of local codes and standard codes (e.g. LOINC, SNOMED), or just to choose a particular set of standard codes (examples: LOINC, SNOMED, RxNorm). Profiles can bind to these value sets instead of the ones defined in the base specification, following these rules:
|
|
|
|
required
| The value set can only contain codes contained in the value set specified by the FHIR specification |
|
extensible
| The value set can contain codes not found in the base value set. These additional codes SHOULD NOT have the same meaning as existing codes in the base value set |
|
preferred
| The value set can contain whatever is appropriate for local use |
|
example
| The value set can contain whatever is appropriate for local use |
Note that local codes are not as interoperable as standard published code systems (e.g. LOINC, SNOMED CT, so it is preferable to use standard code systems.
A profile can change the terminology binding of an element - both strength and value set - within the limits of the base structure it is constraining. This table summarises the changes that can be made to the binding strength:
|
| required | extensible | preferred | example |
| required | yes | no | no | no |
| extensible | yes | yes | no | no |
| preferred | yes | yes | yes | no |
| example | yes | yes | yes |
yes
|
Note that a constraining profile may leave the binding strength the same and change the value set instead. Whatever the constraining profile does, it cannot make codes valid that are invalid in the base structure/profile.
One property that can be declared on profiles that is not declared on the resource or data type definitions is "Must Support". This is a boolean property. If true, it means that systems claiming to conform to a given profile must "support" the element. This is distinct from cardinality. It is possible to have an element with a minimum cardinality of "0", but still expect systems to support the element.
The meaning of "support" is not defined by the base FHIR specification, but can be set to true in a profile. When a profile does this, it SHALL also make clear exactly what kind of "support" is required. Examples might include:
The specific meaning of "Must Support" for the purposes of a particular profile SHALL be described in the
element.definition
, the general ,
the
general
StructureDefinition.description
or in other documentation for the implementation guide the profile is part of. or
in
other
documentation
for
the
implementation
guide
the
profile
is
part
of.
If
creating
a
profile
based
on
another
profile,
Must
Support
can
be
changed
from
false
to
true,
but
cannot
be
changed
from
true
to
false.
Note
that
an
element
that
has
the
property
IsModifier
is
not
necessarily
a
"key"
element
(e.g.
one
of
the
important
elements
to
make
use
of
the
resource),
nor
is
it
automatically
mustSupport
-
however
both
of
these
things
are
more
likely
to
be
true
for
IsModifier
elements
than
for
other
elements.
If creating a profile based on another profile, Must Support can be changed from false to true, but cannot be changed from true to false. Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.
The final thing implementations can do is to define search criteria in addition to those defined in the specification itself. Search criteria fall into one of four categories:
Additional Search Parameters can be defined using the
SearchParameter
resource.
resource.
When this specification describes a profile,, the profile is presented in 5 different forms:
This presents a short summary of the profile - a combination of the author's summary, and some automatically generated summary content
This is a view of the differential statement (
see above
and
QICore
.
Note
that
this
comparison
is
generated
by
tooling
under
ongoing
development,
and
is
purely
draft
content
to
demonstrate
the
idea
of
profile
comparison.
©
HL7.org
2011+.
FHIR
DSTU2
(v1.0.2-7202)
generated
on
Sat,
Oct
24,
2015
07:44+1100.
Links:
Search
). For context, additional information not in the differential is also show partially transparent
This is a view of the snapshot produced by the profile (
see above
|
Table
of
Contents
). The information is a comprehensive view of what the profile means
Not one yet
Not one yet
Applications may be required to support more than one profile at a time. A typical example might be an EHR application that is required to support a general purpose data sharing profile (such as
DAF
), and also must support specific profiles for decision support using the same interface.
The impact of supporting two sets of profiles depends on whether resources are being created or consumed. When an application is creating content, it has to create content that conforms to both sets of profiles - that is, the intersection of the profiles. When an application is consuming information, then it must be able to consume content that conforms to either set of profiles - that is, the union of the profiles.
Since applications generally consume and produce resources at the same time, conforming to more than one profile may not be possible, unless the profiles are designed to make statements at different levels - and the case above is one such case, where one profile is focused on data access, provenance, and availability, the other profile is focused on clinical content.
Accordingly, profiles can relate to each other in four different ways. Each profile can be thought of in terms of the set of instances that conform to the profile:
Profiles can be compared to determine their compatibility. One such comparison can be found (no - todo: bring this into the build) between
DAF
and
QICore
. Note that this comparison is generated by tooling under ongoing development, and is purely draft content to demonstrate the idea of profile comparison.
© HL7.org 2011+. FHIR STU3 Ballot (v1.6.0-9663) generated on Thu, Aug 11, 2016 17:07+1000.
QA Page
Links:
Search
|
Version History
|
Table of Contents
|
Compare to DSTU2
| 
|
Propose a change