. Page versions: R3 R2This page is part of the FHIR Specification (v0.11: DSTU 1 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 . Page versions: R3 R2
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.
The resource name as it appears in a RESTful URL is [root]/profile/
This specification describes a set of base resources that are used in many different contexts in healthcare. In order to make this manageable, applications and specifications need to be able to describe restrictions on how one or more resource(s) are used, including defining extensions, and controlling how terminology is used. These descriptions need to be able to be shared through repositories of profile definitions, and need to allow for these usage statements to be published, compared, and used as the basis for code, report and UI generation. All these things are done using a Resource Profile, which itself is a resource.
Profile resources have four main parts:
This page defines the profile resource, and describes how it is used. Note that as part of the specification itself, a full set of profiles for all resources and data types is published.
A FHIR RESTful server serving the profile resource is also a profile repository. HL7 hosts one for public registration of FHIR profiles at (yet to be done).
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 |
| code | A set of terms from external terminologies that may be used to assist with indexing and searching of templates |
| 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:
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:
All of these changed definitions must 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:
defines the following structure:
<Root>
<childA>
<grandChild/>
</childA>
<childB/>
</Root>
or its JSON equivalent. The structure must be coherent - children are never implied, and the path statements must 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.
One common thing in profiles is to take an element that may occur more than once, and describe a series of different restrictions on the elements in the list, and by doing this associate 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 "component" element which may occur multiple times. The profile for Acme, Inc. constrains the component element into 2 different named kinds: an optional systolic and an optional diastolic observation component, which both have a value of type Quantity. Note that to avoid adding clutter to this simplified example, the "type" attribute of Component is shown to be of type code, while its actual definition is CodeableConcept.
Note that the resource is exchanged, and the wire format that is exchanged is not altered by the profile. The item profile names defined in the profile ("systolic", etc. in this list) are never exchanged. A resource instance looks like this:
<Observation>
<component>
<code value="8480-6"/>
<valueQuantity ...>
</component>
<component>
<code value="8462-4"/>
<valueQuantity ...>
</component>
The only way to determine that the first component corresponds to "Systolic" in the profile is to check the values of the elements - in this case, the code element. In order to make this 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 must nominate a "discriminator" - a child element that is used to discriminate between the different slices. The child element must be associated with a fixed value in each of the definitions, or if the child element has a terminology binding, it must 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.
TODO: how does the discriminator work with resource references? - This is a open question under investigation during the current connectathon parallel to the ballot.
Within a profile, a slice will mean that there are multiple entries in the element list with the same path, each with a different name. All slices that are grouped together (no short path in the elements between them) must have the same discriminator element in the profile, and each slice must specify a distinct set of possible values for the element so that the different slice can be differentiated. The value of the discriminator is either a simple name - the name of a child element, or an URI, which is identifies an extension that serves as the discriminator.
An additional reason to use slicing is when a single element has a choice of types, and different types need different definitions, mappings, or constraints.
TODO: how are bundles managed in profiles? - This is a open question under investigation during the current connectathon parallel to the ballot.
A profile can also define extensions. Some profiles only define extensions, and others define extensions as part of a 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, this will mean that there will be duplication between the definition of the extension, and the definitions in the structure where it is used.
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. To do this, ... (todo: fill out the details)
Note that the minimum cardinality of an extension must 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.
This section defines a set of bindings. A binding links from an element that may contain a code 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.
| false | No additional codes are to be used beyond the list provided |
| true | Supplemental codes or plain text may be needed (this is usually because it is reasonable to think that concepts will need to be used which won't be in the defined set of codes) |
| 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.
<Profile xmlns="http://hl7.org/fhir"> <!-- from Resource: extension, narrative, 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 | experimental | review | production | withdrawn | superseded § --> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage § --> <date value="[dateTime]"/><!-- 0..1 Date for this version of the profile § --> <fhirVersion value="[id]"/><!-- 0..1 FHIR Version this profile targets § --> <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) --> <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 Whether slice list is open or closed --> </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 Formal definition --> <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..* Type of the element --> <code value="[code]"/><!-- 1..1 Data type or Resource --> <profile value="[uri]"/><!-- 0..1 Profile.structure to apply --> <bundled value="[boolean]"/><!-- 0..1 If code is a Resource, is it in the bundle? --> </type> <nameReference value="[string]"/><!-- 0..1 To another element constraint (by element.name) --> <value[x]><!-- 0..1 * Fixed value: [as defined for 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 --> <ocl value="[string]"/><!-- 0..1 OCL expression of constraint --> </constraint> <mustSupport value="[boolean]"/><!-- 0..1 If the element must be usable --> <isModifier value="[boolean]"/><!-- 1..1 If this modifies the meaning of other elements --> <binding value="[uri]"/><!-- 0..1 Reference to a binding (local or absolute) --> <mapping> <!-- 0..* Map element to another set of definitions --> <target value="[uri]"/><!-- 1..1 Which mapping this is (v2, CDA, openEHR, etc.) --> <map value="[string]"/><!-- 0..1 Details of the mapping --> </mapping> </definition> </element> </structure> <extensionDefn> <!-- 0..* Definition of an extension --> <code value="[code]"/><!-- 1..1 Identifies the extension in this profile --> <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> <binding> <!-- 0..* Define code sets for coded elements --> <name value="[string]"/><!-- 1..1 Binding name --> <isExtensible value="[boolean]"/><!-- 0..1 Can additional codes be used? --> <conformance value="[code]"/><!-- 0..1 required | preferred | example --> <description value="[string]"/><!-- 0..1 Human explanation of the binding --> <reference[x]><!-- 0..1 uri|Resource(ValueSet) Source of binding content --></reference[x]> </binding> </Profile>
Alternate definitions: Schema/Schematron, Resource Profile
| Path | Definition | Type | Reference |
|---|---|---|---|
| Profile.status | The lifecycle status of a Resource Profile | Fixed | http://hl7.org/fhir/resource-profile-status |
| Profile.structure.type | Either a resource or a data type | Incomplete | http://hl7.org/fhir/defined-types |
| Profile.structure.element.slicing.rules | How slices are interpreted when evaluating an instance | Fixed | http://hl7.org/fhir/resource-slicing-rules |
| Profile.structure.element.definition.type.code | The type of an element - one of the FHIR data types | Incomplete | http://hl7.org/fhir/data-types |
| Profile.structure.element.definition.constraint.severity | Must applications comply with this constraint? | Fixed | http://hl7.org/fhir/constraint-severity |
| Profile.extensionDefn.contextType | How an extension context is interpreted | Fixed | http://hl7.org/fhir/extension-context |
| Profile.binding.conformance | Binding conformance for applications | Fixed | http://hl7.org/fhir/binding-conformance |
| http://loinc.org | LOINC code for the element |
| http://snomed.info | SNOMED-CT code for the element |
| http://hl7.org/v3 | RIM mappin g |
| http://hl7.org/v2 | v2 mapping |
| http://nema.org/dicom | DICOM tag mapping |
| http://w3.org/vcard | vCard equivalent field |
| http://ihe.net/xds | XDS metadata equivalent |
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.
Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.
| Name / Type | Description | Paths |
| _id : token | The logical resource id associated with the resource (must be supported by all servers) | |
| author : string | Name or id of the author of the profile | |
| binding : token | A vocabulary binding code | |
| code : token | A code for the profile in the format uri::code (server may choose to do subsumption) | |
| date : date | The profile publication date | |
| extension : token | An extension code (use or definition) | |
| name : string | A portion of the name of the profile | |
| reference : token | An id of another profile referenced in the profile | |
| resource : token | A resource constrained in a profile | |
| status : token | The current status of the profile | |
| type : token | Type of resource that is constrained in the profile | |
| word : text | A word somewhere in the definition of the profile or the elements in the resource. (Common words - 'and', etc. - are often not supported) |