This page is part of the FHIR Specification (v0.0.82: DSTU 1). 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: R3 R2

• Content
• Examples
• Formal Definitions
• Mappings
• Profiles

6.14 Resource Profile - Content

A Resource Profile - a statement of use of one or more FHIR Resources. It may include constraints on Resources and Data Types, Terminology Binding Statements and Extension Definitions.

6.14.3 Background and Context

6.14.3.1 Metadata

The profile resource has a set of metadata that is mostly shared with the Value Set and Conformance resources. The metadata describes the profile, and helps find the profile when registered in profile repositories.

identifier	The identifier that is used to identify this profile when it is referenced in a specification, model, design or an instance (should be globally unique URI, OID, or UUID)
version	The identifier that is used to identify this version of the profile when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the profile author manually and the value should be a timestamp. Note that there may be multiple resource versions of the profile that have this same identifier. The resource will have updates that create new versions for technical reasons, whereas the stated version number needs to be under the author's control
name	A free text natural language name identifying the Profile
publisher	Details of the individual or organization who accepts responsibility for publishing the profile. This helps establish the "authority/credibility" of the profile.
telecom	Contact details to assist a user in finding and communicating with the publisher
description	A free text natural language description of the profile and its use
requirements	The Scope and Usage that this profile was created to meet
code	A set of terms from external terminologies that may be used to assist with indexing and searching of profiles
status	The status of the profile allows filtering of profiles that are appropriate for use vs. not. See the Status Codes
experimental	This profile was authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usage
date	The date that this version of the profile was published
fhirVersion	The version of the FHIR specification on which this profile is based. It is not necessary to specify the version, as most profiles are valid across multiple versions, and the validity of a profile against a particular version of FHIR can easily be checked by tooling.

Notes:

• The name of the profile is not required to be globally unique, but the name should have some scoping information (i.e. Acme Inc. (USA), Allergy List)
• Multiple codes may be assigned to the profile. These may either describe the profile, the focus of the profile or both. They are solely to help find the profile by searching for structured concepts.

6.14.3.2 Structure

This section specifies restrictions on the content of a resource or a data type. Each structure has a name, which as an internal name unique in the scope of the profile that is used to reuse the structure, and the type that it restricts, which is either a resource or data type defined in the FHIR specification. The following kinds of statements can be made about how a resource or data type is used:

• Restricting the cardinality of the element. e.g. the base might allow 0..*, and a particular application might support 1..2
• Ruling out use of an element by setting its maximum cardinality to 0
• Making additional invariants on the content of nested elements within the resource (expressed as XPath statements)
• Restricting the types for an element that allows multiple types
• Requiring a typed element or the target of a resource reference to conform to a profile declared elsewhere
• Specifying a binding to a different terminology value set
• Providing alternative definitions for the elements defined in a Resource to explain how they are used in the context of the Profile
• Providing more specific or additional mappings (e.g. to v2 or v3) for the resource when used in a particular context

All of these changed definitions SHALL be restrictions that are consistent with the rules defined in the base resource in the FHIR Specification. Note that some of these restrictions can be enforced by tooling (and are by the FHIR tooling), but others cannot be automatically enforced.

A structure definition consists of a linear list of element declarations. 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:

• Root
• Root.childA
• Root.childA.grandchild1
• Root.childB

defines the following structure:

 <Root>
   <childA>
     <grandChild/>
   </childA>
   <childB/>
 </Root>

or its JSON equivalent. The structure SHALL be coherent - children are never implied, and the path statements SHALL always be in order. The element list is a linear list rather than being explicitly nested because profile structures are frequently used in multiple places within a single profile, and this re-use is easier in a flat structure.

Profiles are always complete and static. This means that there is never a need to consult any additional profiles to fully understand the element structure that is defined, and there is no need to perform comparison between any profiles to determine the meaning of any profile.

6.14.3.3 Slicing

One common feature of profiles is to take an element that may occur more than once (e.g. in a list), and describe a series of different restrictions on the elements in the list with associated additional meaning with each element, so that the list is split into a series of individual elements or sub-lists. In FHIR, this operation is known as "Slicing" a collection.

Here is an example to illustrate the process:

In this example, the base resource defines the "related" element which may occur multiple times. Each related element has a "type" element, and a "target" element which identifies another observation. In this diagram, the contents of the target element are shown in the inner box instead of the showing the target reference explicitly. Note that to avoid adding clutter to this simplified example, the "name" attribute of Observation is shown as (code) not a full CodeableConcept.

The profile for Blood Pressure constrains the related element list into 2 different elements: a systolic element, and a diastolic element. Each of these elements has a fixed value for the type element, and a the profile also fixes the contents of the target observation as well, specifying a fixed LOINC code for the name, and specifying that 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 profile. This means that the item profile names defined in the profile ("systolic", etc. in this example) are never exchanged. A resource instance looks like this:

 <Observation>
   ...
   <related>
     <type value="component"/>
     <target ...>
   </related>
   <related>
     <type value="component"/>
     <target ...>
   </related>
 </Observation>

The only way to determine that the first related item corresponds to "Systolic" in the profile is to check the values of the elements - in this case, the name element in the target resource.

In order to make slicing easy to use, particularly in the context of code generation tools that work with profiles, any time slicing is performed in a profile, the profile SHALL nominate a "discriminator" - a contained element that is used to discriminate among the different slices. The profile SHALL fix the value of the contained element for each slice, or if the contained element has a terminology binding, it SHALL be associated with a complete binding with a version specific Value Set reference that enumerates the possible codes in the value set, and where there is no overlap between the codes in the value sets between slices.

Within a profile, a slice is defined using multiple element entries that share a path but have distinct names. These entries together form a "slice group" that is:

1. Initiated by a "slicing entry" That is, the first element in a slice group must contain a slicing property that defines the discriminator for all members of the group.
2. Mutually exclusive. This means that each element in a slice group SHALL describe a distinct set of values for the group's discriminator. Because of this constraint, an element in a resource instance will never match more than one element in a given slice group.
3. Serialized as a group. The entries in a slice group must be adjacent in a serialized Profile, or, if there are any intervening elements, those elements must be "compatible with" the group. Concretely, this means that any intervening elements must have a path that starts with the slice groups's path. For example, an element with a path of Observation.name.extension would be compatible with (and thus, would not "break up") a slice group whose path was Observation.name

The value of the discriminator is either a path name that identifies the child element using a dotted notation, or a URI, which identifies an extension that serves as the discriminator (and which must be found on the element at which the slicing occurs). In the case above, the discriminator is "target.name" (the fact that there is a resource boundary between "target" and "name" is implied, not represented directly).

6.14.3.4 Extension Definitions

A profile can also define extensions. Some profiles only define extensions, and others define extensions as part of defining one or more structures. For an extension definition, the profile defines the code that identifies the extension. The full URI that refers to the extension when it is used in a resource is the identifier (from the metadata above) and then # + the code.

The extension definition also defines the context where the extension can be used (usually a particular path or a data type), and then defines it using the same details used to profile the structural elements.

Note that in the case of a profile that defines an extension, and then uses it, the extension will appear both in the extension definition section, and in one or more places in the structure defined by the profile.

For further discussion of defining and using extensions, along with some examples, see Extensibility.

6.14.3.4.1 Using Extensions in Structures

Defining a extension means that it can be used in a resource somewhere. To actually use a resource, 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 be 0.

6.14.3.5 Binding Definitions

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 value set 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 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 two properties that define how the set of codes is used: isExtensible and conformance.

• isExtensible indicates whether additional codes are allowed beyond those in the defined set of codes.

  false	No additional codes are to be used beyond the list provided
  true	Supplemental codes or plain text may be needed (this is common because it is reasonable to think that concepts will need to be used which won't be in the defined set of codes)

• Conformance indicates the expectations for implementers of the specification. There are three possible values:

  required	Only codes in the specified set are allowed. If the strength is 'extensible', other codes may be used for concepts not covered by the value set but cannot be used for concepts covered by the bound code list, even if a profile constrains out some of those codes).
  preferred	For greater interoperability, implementers are strongly encouraged to use the bound set of codes, however alternate codes may be used in profiles if necessary without being considered non-conformant.
  example	The codes in the set are an example to illustrate the meaning of the field. There is no particular preference for its use.

The interplay between the meaning of these is subtle but sometimes important. The following table helps define the meanings:

Conformance	isExtensible=false	isExtensible=true
Required	Implementers SHALL use a code from the defined set	Implementers SHALL use a code from the defined set if one is applicable, but otherwise may provide their own code or use text
Preferred	Implementers SHOULD use a code from the defined set	Implementers SHOULD use a code from the defined set if one is applicable, but MAY provide their own code or use text
Example	Implementers MAY use a code from the defined set	Implementers MAY use a code from the defined set or provide their own code or use text

A profile can define a set of bindings that it uses directly, or it can define a set of bindings for re-use in other profiles. To use bindings in other profiles, just provide an absolute reference. This is a reference to a binding in the same profile:

  <binding value="te:OperationOutcomeSource"/>

This is a reference to a binding in some other profile:

  <binding value="http://hl7.org/fhir/tooling/extensions#OperationOutcomeSource"/>

Bindings can reference value sets by version or independent of version. Value sets may themselves reference other value sets as well as code systems by version or independent of version. Unless all references are version-specific, it is possible that the set of codes permitted in the value set could change over time.

6.14.4 Resource Content

This resource is referenced by [Conformance]

<Profile xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: extension, modifierExtension, language, text, and contained -->
 <identifier value="[string]"/><!-- 0..1 Logical id to reference this profile § -->
 <version value="[string]"/><!-- 0..1 Logical id for this version of the profile § -->
 <name value="[string]"/><!-- 1..1 Informal name for this profile § -->
 <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) § -->
 <telecom><!-- 0..* Contact Contact information of the publisher § --></telecom>
 <description value="[string]"/><!-- 0..1 Natural language description of the profile § -->
 <code><!-- 0..* Coding Assist with indexing and finding § --></code>
 <status value="[code]"/><!-- 1..1 draft | active | retired § -->
 <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage § -->
 <date value="[dateTime]"/><!-- 0..1 Date for this version of the profile § -->
 <requirements value="[string]"/><!-- 0..1 Scope and Usage this profile is for -->
 <fhirVersion value="[id]"/><!-- 0..1 FHIR Version this profile targets § -->
 <mapping>  <!-- 0..* External specification that the content is mapped to -->
  <identity value="[id]"/><!-- 1..1 Internal id when this mapping is used -->
  <uri value="[uri]"/><!--  0..1 Identifies what this mapping refers to -->
  <name value="[string]"/><!--  0..1 Names what this mapping refers to -->
  <comments value="[string]"/><!-- 0..1 Versions, Issues, Scope limitations etc -->
 </mapping>
 <structure>  <!--  0..* A constraint on a resource or a data type -->
  <type value="[code]"/><!--  1..1 The Resource or Data Type being described -->
  <name value="[string]"/><!-- 0..1 Name for this particular structure (reference target) -->
  <publish value="[boolean]"/><!-- 0..1 This definition is published (i.e. for validation) -->
  <purpose value="[string]"/><!-- 0..1 Human summary: why describe this resource? -->
  <element>  <!-- 0..* Definition of elements in the resource (if no profile) -->
   <path value="[string]"/><!-- 1..1 The path of the element (see the formal definitions) -->
   <representation value="[code]"/><!-- 0..* How this element is represented in instances -->
   <name value="[string]"/><!-- 0..1 Name for this particular element definition (reference target) -->
   <slicing>  <!-- 0..1 This element is sliced - slices follow -->
    <discriminator value="[id]"/><!-- 1..1 Element that used to distinguish the slices -->
    <ordered value="[boolean]"/><!-- 1..1 If elements must be in same order as slices -->
    <rules value="[code]"/><!-- 1..1 closed | open | openAtEnd -->
   </slicing>
   <definition>  <!-- 0..1 More specific definition of the element -->
    <short value="[string]"/><!-- 1..1 Concise definition for xml presentation -->
    <formal value="[string]"/><!-- 1..1 Full formal definition in human language -->
    <comments value="[string]"/><!-- 0..1 Comments about the use of this element -->
    <requirements value="[string]"/><!-- 0..1 Why is this needed? -->
    <synonym value="[string]"/><!-- 0..* Other names -->
    <min value="[integer]"/><!-- 1..1 Minimum Cardinality -->
    <max value="[string]"/><!--  1..1 Maximum Cardinality (a number or *) -->
    <type>  <!-- 0..* Data type and Profile for this element -->
     <code value="[code]"/><!-- 1..1 Name of Data type or Resource -->
     <profile value="[uri]"/><!--  0..1 Profile.structure to apply -->
     <aggregation value="[code]"/><!--  0..* contained | referenced | bundled - how aggregated -->
    </type>
    <nameReference value="[string]"/><!--  0..1 To another element constraint (by element.name) -->
    <value[x]><!--  0..1 * Fixed value: [as defined for a primitive type] --></value[x]>
    <example[x]><!-- 0..1 * Example value: [as defined for type] --></example[x]>
    <maxLength value="[integer]"/><!-- 0..1 Length for strings -->
    <condition value="[id]"/><!-- 0..* Reference to invariant about presence -->
    <constraint>  <!-- 0..* Condition that must evaluate to true -->
     <key value="[id]"/><!-- 1..1 Target of 'condition' reference above -->
     <name value="[string]"/><!-- 0..1 Short human label -->
     <severity value="[code]"/><!-- 1..1 error | warning -->
     <human value="[string]"/><!-- 1..1 Human description of constraint -->
     <xpath value="[string]"/><!-- 1..1 XPath expression of constraint -->
    </constraint>
    <mustSupport value="[boolean]"/><!-- 0..1 If the element must supported -->
    <isModifier value="[boolean]"/><!-- 1..1 If this modifies the meaning of other elements -->
    <binding>  <!--  0..1 ValueSet details if this is coded -->
     <name value="[string]"/><!--  1..1 Descriptive Name -->
     <isExtensible value="[boolean]"/><!--  1..1 Can additional codes be used? -->
     <conformance value="[code]"/><!--  0..1 required | preferred | example -->
     <description value="[string]"/><!--  0..1 Human explanation of the value set -->
     <reference[x]><!--  0..1 uri|Resource(ValueSet) Source of value set --></reference[x]>
    </binding>
    <mapping>  <!-- 0..* Map element to another set of definitions -->
     <identity value="[id]"/><!--  1..1 Reference to mapping declaration -->
     <map value="[string]"/><!-- 1..1 Details of the mapping -->
    </mapping>
   </definition>
  </element>
  <searchParam>  <!-- 0..* Search params defined -->
   <name value="[string]"/><!-- 1..1 Name of search parameter -->
   <type value="[code]"/><!-- 1..1 number | date | string | token | reference | composite | quantity -->
   <documentation value="[string]"/><!-- 1..1 Contents and meaning of search parameter -->
   <xpath value="[string]"/><!-- 0..1 XPath that extracts the parameter set -->
   <target value="[code]"/><!-- 0..* Types of resource (if a resource reference) -->
  </searchParam>
 </structure>
 <extensionDefn>  <!--  0..* Definition of an extension -->
  <code value="[code]"/><!--  1..1 Identifies the extension in this profile -->
  <display value="[string]"/><!-- 0..1 Use this name when displaying the value -->
  <contextType value="[code]"/><!-- 1..1 resource | datatype | mapping | extension -->
  <context value="[string]"/><!-- 1..* Where the extension can be used in instances -->
  <definition><!-- 1..1 Content as for Profile.structure.element.definition Definition of the extension and its content --></definition>
 </extensionDefn>
 <query>  <!-- 0..* Definition of a named query -->
  <name value="[string]"/><!-- 1..1 Special named queries (_query=) -->
  <documentation value="[string]"/><!-- 1..1 Describes the named query -->
  <parameter><!-- 0..* Content as for Profile.structure.searchParam Parameter for the named query --></parameter>
 </query>
</Profile>

Alternate definitions: Schema/Schematron, Resource Profile

6.14.4.1 Terminology Bindings

6.14.4.2 Constraints

• Inv-8: SHALL define at least one structure constraint or extension definition (xpath: exists(f:structure) or exists(f:extensionDefn))
• Inv-15: Where multiple structures exist with the same type, they SHALL have names (xpath: count(f:structure[not(f:name)]) = count(distinct-values(f:structure[not(f:name)]/f:type/@value)))
• Inv-16: Extension definition codes must be unique (xpath: count(f:extensionDefn) = count(distinct-values(f:extensionDefn/f:code/@value)))
• Inv-17: There can't be multiple structures with the same type and name (xpath: not(exists(for $structure in f:structure return $structure/preceding-sibling::f:structure[f:type/@value=$structure/f:type/@value and f:name/@value = $structure/f:name/@value])))
• Inv-27: Structure name must be unique (xpath: count(distinct-values(f:structure/f:name/@value)) =count(f:structure/f:name))
• Inv-28: Query name must be unique (xpath: count(distinct-values(f:query/f:name/@value)) =count(f:query/f:name))
• Inv-26: On Profile.mapping: Must have at a name or a uri (or both) (xpath on f:Profile/f:mapping: exists(f:uri) or exists(f:name))
• Inv-12: On Profile.structure: Only complex types can be constrained, not primitive types such as string etc. (xpath on f:Profile/f:structure: upper-case(substring(f:type,1,1))=substring(f:type,1,1))
• Inv-18: On Profile.structure: Element paths must be unique - or not (LM) (xpath on f:Profile/f:structure: count(f:element) >= count(distinct-values(f:element/f:path/@value)))
• Inv-29: On Profile.structure: Parameter names must be unique within structure (xpath on f:Profile/f:structure: count(distinct-values(f:searchParam/f:name/@value)) =count(f:searchParam/f:name))
• Inv-11: On Profile.structure.element: Must have either a slice or a definition, but not both (xpath on f:Profile/f:structure/f:element: exists(f:slicing) != exists(f:definition))
• Inv-20: On Profile.structure.element: An element must either be a definition or a slicing descriptor, never both. (xpath on f:Profile/f:structure/f:element: exists(f:slicing)!=exists(f:definition))
• Inv-21: On Profile.structure.element: An element that's a slicing descriptor must not be preceded by an element that starts with the same path and must be followed by an element with exactly the same path. (xpath on f:Profile/f:structure/f:element: not(f:slicing) or (not(starts-with(preceding-sibling::f:element[1]/f:path/@value, current()/f:path/@value)) and following-sibling::f:element[1]/f:path/@value=current()/f:path/@value))
• Inv-2: On Profile.structure.element.definition: Either a namereference or a fixed value (but not both) is permitted (xpath on f:Profile/f:structure/f:element/f:definition: not(exists(f:nameReference) and exists(f:*[starts-with(local-name(.), 'value')])))
• Inv-7: On Profile.structure.element.definition: Binding can only be present for coded elements (xpath on f:Profile/f:structure/f:element/f:definition: not(exists(f:binding)) or f:type/f:code/@value=('code','Coding','CodeableConcept','Quantity'))
• Inv-10: On Profile.structure.element.definition: Value may only be specified if the type consists of a single repetition that has a type corresponding to one of the primitive data types. (xpath on f:Profile/f:structure/f:element/f:definition: not(exists(f:*[starts-with(local-name(.), 'value')])) or (count(f:type)=1 and f:type/f:code[substring(@value,1,1)=lower-case(substring(@value,1,1))]))
• Inv-19: On Profile.structure.element.definition: Element names must be unique (xpath on f:Profile/f:structure/f:element/f:definition: count(f:element[f:name]) = count(distinct-values(f:element/f:name/@value)))
• Inv-22: On Profile.structure.element.definition: If a definition has multiple types with the same code, each must specify a profile (xpath on f:Profile/f:structure/f:element/f:definition: count(f:type[not(f:profile)]) = count(distinct-values(f:type[not(f:profile)]/f:code/@value)))
• Inv-23: On Profile.structure.element.definition: Types must be unique by the combination of code and profile (xpath on f:Profile/f:structure/f:element/f:definition: not(exists(for $type in f:type return $type/preceding-sibling::f:type[f:code/@value=$type/f:code/@value and f:profile/@value = $type/f:profile/@value])))
• Inv-24: On Profile.structure.element.definition: Constraints must be unique by key (xpath on f:Profile/f:structure/f:element/f:definition: count(f:constraint) = count(distinct-values(f:constraint/f:key/@value)))
• Inv-25: On Profile.structure.element.definition: Constraint names must be unique. (xpath on f:Profile/f:structure/f:element/f:definition: count(f:constraint[f:name]) = count(distinct-values(f:constraint/f:name/@value)))
• Inv-6: On Profile.structure.element.definition.max: Max SHALL be a number or "*" (xpath on f:Profile/f:structure/f:element/f:definition/f:max: @value='*' or (normalize-space(@value)!='' and normalize-space(translate(@value, '0123456789',''))=''))
• Inv-9: On Profile.structure.element.definition.type: Aggregation may only be specified if one of the allowed types for the element is a resource (xpath on f:Profile/f:structure/f:element/f:definition/f:type: not(exists(f:aggregation)) or exists(f:code[starts-with(@value, 'Resource(')]))
• Inv-3: On Profile.structure.element.definition.binding: provide either a reference or a description (or both) (xpath on f:Profile/f:structure/f:element/f:definition/f:binding: (exists(f:referenceUri) or exists(f:referenceResource)) or exists(f:description))
• Inv-14: On Profile.structure.element.definition.binding: Example value sets are always extensible (xpath on f:Profile/f:structure/f:element/f:definition/f:binding: not(f:Conformance/value='example' and f:isExtensible.value='false'))
• Inv-13: On Profile.structure.element.definition.binding.reference[x]: uri SHALL start with http:// or https:// (xpath on f:Profile/f:structure/f:element/f:definition/f:binding/f:reference[x]: starts-with(@value, 'http:') or starts-with(@value, 'https:'))
• Inv-5: On Profile.extensionDefn.code: Codes SHALL be unique in the context of a profile (xpath on f:Profile/f:extensionDefn/f:code: count(ancestor::f:Profile/f:extensionDefn/f:code[@value=current()/@value])=1)

6.14.5 Interpretation Notes:

• The name of a resource constraint (Profile.structure.name) is used as a logical target for both internal and external references to the profile.
  • A internal reference is made from Profile.structure.element.definition.type.profile to re-use the constraints declared in another structure, either in the same profile or another. If the reference is within the same resource, the uri is a relative reference with the form #[name]. If the reference is to another resource, it should be either an absolute URI that termintes with a #[name]
  • An external reference is one made to the profile from a Conformance Statement or a Profile Tag. For these references, the [#name] portion is optional. If there is no #name portion, the reference doesn't identify a particular structural definition in the instance, and it is an error if there is more than one matching structure for the resource type in context that might apply when the Profile reference is used
• The constraint statement has a flat list of elements. The path element provides the overall structure and it SHALL match the structure and names in the resource structure exactly.
• The condition element is used to assert that a constraint defined on another element affects the allowed cardinality of this element.
• The type is used to specify which types apply when the underlying resource allows a choice of types. When the type of the element is fixed in the underlying resource definitions, it should still be stated in the profile. The type is optional because repeating groups of elements do not have a type.
• The definition (short, formal, comments and the mappings) for an element is provided so that the resource profile can provide a more specific definition for the field in a specific context. For instance, the underlying resource definition might be "Result value" and the more specific resource definition could be "Plasma Cholesterol Test Value". The meaning needs to be consistent with the underlying definition, but narrower - a constraint on it.
• For an element with a maximum cardinality of 1, there can only be one entry in the value list, which is either a literal fixed type (with an element name matching the type of the fixed value) or a name, which is a reference to a named constraint pattern. If the element has a maximum cardinality of >1, then there can be multiple values - again, either fixed values with a type or a named constraint. Each of these appears in the list with the order and cardinality specified. By this means, a list may be "sliced" into a series of different components.
• There can be more than one entry for each element path. The constraint specification can define multiple different constraints for any element and then use them in different places. In practice, this is useful when slicing a list and the differently named constraint profiles are differentiated using the value[x] element. The name of the element constraint SHALL be unique within the constraint specification for that resource. If a constraint does not have a name, it applies to the base resource and SHALL be found in the correct place in the structure.
• Closed is only relevant if the underlying element has a max cardinality > 1.
• For an extension definition, the cardinality constraints are limits on the constraints of any reference to the extension in a profile. For example, if the minimum cardinality of an extension is 1 when it is defined, then any profile that includes that extension in the instance SHALL include it with a minimum cardinality of 1 and therefore any instance that conforms to the profile SHALL include the extension. Note, however, that if the extension is simply directly referenced in an instance rather than applied through a profile, the minimum cardinality doesn't apply, though the maximum one still does.
• For xpath constraints, the prefix "f" should be used for "http://hl7.org/fhir", and "h" for "http://www.w3.org/1999/xhtml". XPath constraints are written against the XML representation, but SHALL be true in any other representation as well
• When using xpath to make constraints about the relationship between the contents of the narrative and the contents of the data elements, the element against which the rule is expressed is the one against which the error will be reported.

6.14.5.1 Common Mapping Targets

6.14.6 Profiled FHIR

If a profile is unambiguous, then the FHIR profile tooling (ref to be provided when the tooling exists) is able to generate reference implementation based object models that express the profiled model natively, where the object interface does not include prohibited elements, treats declared extensions as primary properties and slices lists according to the profile. This eases the burden on an implementer, though this object model can only be used with a sub-set of the possible resources.

The tooling is also able to generate bi-directional transforms between the normal XML format and an XML representation of this profiled object model and schema for this profiled XML representation. This XML form has extensions promoted into the primary XML form by using the extension code as the XML name and sliced lists are renamed to use the Profile.resource.element.name as the XML element name. Profiles are only suitable for this use if they ensure that there are no clashing extension names when the extension definition spaces are ignored and that the sliced list names are appropriate.

Implementations are allowed to exchange this profiled XML format. Implementations that do so are not fully conformant to FHIR; instead they can claim to be conformant to "Profiled FHIR". Implementations should consider carefully before adopting this approach; while it will reduce the amount of work required to initially implement particular profiles, it will increase the amount of work required to exchange this data with other communities or to re-use tooling and applications that are also used in other contexts. This cost should particularly be considered in light of the fact that the previously discussed tooling allows applications to be written as though they are dealing with "Profiled FHIR" instances when they are in fact sending and receiving fully conformant FHIR instances.

6.14.7 Search Parameters

Search parameters for this resource. The standard parameters also apply. See Searching for more information about searching in REST, messaging, and services.