6.14 Profile リソース

Home ＞ Infrastructure ＞ Profile [profile]

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:

1. A metadata section the describes the profile, and supports registry searching
2. Structures that define and describe how a Resource or Data Type is used
3. Extension Definitions that define extensions that can be used in structures
4. Bindings that describe a particular way that terminology is used

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.

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 template, the focus of the template or both. They are solely to help find the profile by searching for structured concepts.

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 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 thepath 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:

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.

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

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

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

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.

Alternate definitions: Schema/Schematron, Resource Profile

• Inv-8: Must define at least one resource constraint, extension definition or binding (xpath: exists(f:structure) or exists(f:extensionDefn) or exists(f:binding))
• Inv-1: On Profile.structure: Provide either a profile reference or constraints on the resource elements (but not both) (xpath on f:Profile/f:structure: exists(f:profile) != exists(f:element))
• 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-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-6: On Profile.structure.element.definition.max: Max must 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: Bundled 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:bundled)) or exists(f:code[starts-with(@value, 'Resource(')]))
• Inv-5: On Profile.extensionDefn.code: Codes must 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)
• Inv-3: On Profile.binding: provide either a reference or a description (xpath on f:Profile/f:binding: (exists(f:referenceUri) or exists(f:referenceResource)) or exists(f:description) or exists(f:name))
• Inv-14: On Profile.binding: Example value sets are always extensible (xpath on f:Profile/f:binding:not(f:conformance/@value='example' and f:isExtensible.value='false'))
• Inv-11: On Profile.binding.name: Binding name must be unique in the context of a profile (xpath on f:Profile/f:binding/f:name:count(ancestor::f:Profile/f:binding/f:name[@value=current()/@value])=1)
• Inv-13: On Profile.binding.reference[x]: uri must start with http:// or https:// (xpath on f:Profile/f:binding/f:reference[x]: starts-with(@value, 'http:') or starts-with(@value, 'https:'))

• The name of a resource constraint (Profile.structure.name) is only used as a logical target for .element.type.profile. A reference may reference another resource constraint in the same Resource Profile by Profile.resource.name as #[name] or a different resource constraint in another profile by an absolute uri. In the case of an absolute uri, it must resolve literally or logically to a Resource Profile and specify a #[name] portion in the URI that references a particular constraint in the target profile by name.
• The constraint statement has a flat list of elements. The path element provides the overall structure and it must 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 invoked using the values element. The name of the element constraint must be unique within the constraint specification for that resource. If a constraint does not have a name, it applies to the base resource and must 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 must include it with a minimum cardinality of 1 and therefore any instance that conforms to the profile must 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 must 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.

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.