This page is part of the FHIR Specification (v0.01: Historical Archive Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
todo: conformance and realms
Constraint
This specification describes a set of base resources that are used in many different
contexts in healthcare. In order to make this manageable, applications need to be
able to provide a structured statement of which elements of a resource are used,
and how. In addition the existing elements, the use of extensions also needs to
be described. These structured statements are actually constraint statements that
describe a particular pattern of usage. As a general tool, they find use in several different
contexts:
- Describing testable conformance rules for applications that read and write FHIR resources
- Making rules about how information is represented in jurisdictions and institutions
- Describing common clinical patterns of use of general resources
The final form of these conformance descriptions is a constraint statement, which may
be used at run time to assist with application to application negotiation, or it may
be used at design time or even purchase time to assist implementers to understand the
capabilities of the system. This specification uses the general constraint statement
defined here in 4 contexts:
The constraint statement is a fixed XML format that is used to represent the core part of
these various descriptions of use, which is the actual contents of a resource.
Unpicking
One common operation in a constraint statement is to take an element that may occur more
than once, and describe a series of different constraints on the elements in the list.
In this way, the list is split into a series of individual elements or sub-lists.
In FHIR, this operation is known as "unpicking" a list. Here is an example to illustrate the
process:
| Resource Definition |
|
|
Profile for Acme, Inc |
relationship [0..*]
type : Coding
name : string |
|
|
parent [1..2]
type = PAR
name...
guardian [0..1]
type = GUARD
name...
child [0..6]
type = CHILD
name...
|
In this example, the resource definition defines the relationship element which may occur
multiple times. The profile for Acme, Inc constrains the relationships into 3 different kinds:
1 or 2 parents, up to 6 children, and maybe a guardian. No other relationships are supported
by the Acme system.
Note that in FHIR, only the resource is ever actually exchanged. The profile describes a way of
using the resource, but the item profile names ("parent", etc in this list) are never exchanged.
In order the unpicking to be useful, systems must be able to determine which
relationships in the relationship list that is actually exchanged are parent, child, or
guardian; in this particular case, the determination is achieved by fixing the value of the
relationship type element. Fixing a code value is the most common way to unpick a list.
Constraint Statement
Note that the context of appearing will make it clear whether this resource constraint specification
is written from the context of the resource instance, a writing or a reading application
<x xmlns="http://www.hl7.org/fhir">
<type> mand code The Type of the resource being described</type>
<profile> cond uri Resource Profile that supplies the constraints</profile>
<name> opt string Name for this Constraint Statement</name>
<purpose> opt string Human summary: why describe this resource?</purpose>
<element> cond <!-- Zero+ -->
<path> mand string The path of the element (see the formal definitions)</path>
<name> opt string Name this constraint for re-use & unrolling</name>
<purpose> opt string Human summary: why describe this element?</purpose>
<min> mand integer Minimum Cardinality</min>
<max> mand code Maximum Cardinality (a number or *)</max>
<type> opt code Type of the element</type>
<conformance> mand code Mandatory|Conditional|Optional|Prohibited</conformance>
<condition> cond string Condition if conformance=Conditional</condition>
<mustSupport> opt boolean If the element must be usable</mustSupport>
<mustUnderstand> opt boolean If the element must be understood</mustUnderstand>
<definition> opt string More specific definition</definition>
<mapping> opt <!-- Zero+ -->
<target> mand string Which mapping this is (v2, CDA, openEHR, etc)</target>
<map> opt string Details of the mapping</map>
</mapping>
<resource> cond <!-- If context includes aggregation and type=Resource() -->
<aggregated> mand boolean Whether this resource is aggregated</aggregated>
<profile> opt uri Reference to a Resource Profile</profile>
</resource>
<valueSet> opt string Value set id (only if coded)</valueSet>
<value> opt <!-- Zero+ -->
<name> cond string Reference to another element by element.name</name>
<[type]> cond Fixed value: [as defined for type]</[type]>
</value>
</element>
</x>
Terminology Bindings
- Constraint.type is bound to the concept domain ResourceType which has the allowed values of any defined Resource Type name
- Constraint.element.type is bound to the concept domain DataType which has the allowed values of any defined data Type name (including Resource)
- Constraint.element.conformance is bound to the concept domain ConformanceType: "The conformance value for an element". Possible values:
| Mandatory | The element is or must always be present without a dataAbsentReason |
| Conditional | The element may need to be present (with no dataAbsentReasons) depending on the condition |
| Optional | The element may or may not be present |
| Prohibited | The element can not present or will be rejected if received |
Notes:
- The name of the resource is only used as a logical target for .element.aggregation.reference. which may reference another resource
constraint in same resource by this name (#[name]), or a different resource by an absolute uri. In the case of an absolute uri, it
must resolve literally or logically to a Resource Profile
- The constraint statement has a flat list of elements. The path element provides the overall structure and matches the value in the formal definitions exactly
- The condition element must be present if the conformance value is conditional. There is no formal computable grammar for the condition
- The type of the element is mostly fixed in the underlying resource definitions, so it can be left out of the constraint specification.
However when the type is open (resource link to a choice, or a link to any resource, or a choice of data types), then
this field can be used to pick a narrower set of types
- Definition is provided so that the constraint statement 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. If no definition is provided, the inherited definition
still applies
- There can be more than one definition 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 for elements in 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
- 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 type of "list", 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 "unpicked" into a series of different components
- The extensions element can be unpicked using this mechanism in order to define the applicable extensions
TODO: Is any control over narrative required?
Formal Definitions
The formal definitions for the elements above. Also available as an XML file.
| Constraint |
| Control | Mandatory, 1..1 |
| Constraint.type |
| Definition | The Type of the resource being described |
| Control | Mandatory, 1..1 |
| Type | code from ResourceType |
| Constraint.profile |
| Definition | Reference to a resource profile which includes the constraint statement that applies to this resource |
| Control | Conditional, 0..1: Provide either a profile reference or constraints on the resource elements |
| Type | uri |
| Constraint.name |
| Definition | The name of this aggregation profile |
| Control | Optional, 0..1 |
| Type | string |
| Comments | This field is the target for a named aggregation definition (aggregation.name) |
| Constraint.purpose |
| Definition | Human summary: why describe this resource? |
| Control | Optional, 0..1 |
| Type | string |
| Constraint.element |
| Control | Conditional, 0..*: Provide either a profile reference or constraints on the resource elements |
| Constraint.element.path |
| Definition | The path of the element (see the formal definitions) |
| Control | Mandatory, 1..1 |
| Type | string |
| Constraint.element.name |
| Definition | Name this constraint for re-use & unrolling |
| Control | Optional, 0..1 |
| Type | string |
| Constraint.element.purpose |
| Definition | Human summary: why describe this element? |
| Control | Optional, 0..1 |
| Type | string |
| Constraint.element.min |
| Definition | Minimum Cardinality |
| Control | Mandatory, 1..1 |
| Type | integer |
| Constraint.element.max |
| Definition | Maximum Cardinality (a number or *) |
| Control | Mandatory, 1..1 |
| Type | code |
| Constraint.element.type |
| Definition | Type of the element |
| Control | Optional, 0..1 |
| Type | code from DataType |
| Constraint.element.conformance |
| Definition | Mandatory|Conditional|Optional|Prohibited |
| Control | Mandatory, 1..1 |
| Type | code from ConformanceType |
| Constraint.element.condition |
| Definition | Condition if conformance=Conditional |
| Control | Conditional, 0..1: Required if conformance = conditional |
| Type | string |
| Constraint.element.mustSupport |
| Definition | If the element must be usable |
| Control | Optional, 0..1 |
| Type | boolean |
| Constraint.element.mustUnderstand |
| Definition | If the element must be understood |
| Control | Optional, 0..1 |
| Type | boolean |
| Constraint.element.definition |
| Definition | More specific definition |
| Control | Optional, 0..1 |
| Type | string |
| Constraint.element.mapping |
| Control | Optional, 0..* |
| Constraint.element.mapping.target |
| Definition | Which mapping this is (v2, CDA, openEHR, etc) |
| Control | Mandatory, 1..1 |
| Type | string |
| Constraint.element.mapping.map |
| Definition | Details of the mapping |
| Control | Optional, 0..1 |
| Type | string |
| Constraint.element.resource |
| Definition | If context includes aggregation and type=Resource() |
| Control | Conditional, 0..1: If context includes aggregation and type=Resource() |
| Constraint.element.resource.aggregated |
| Definition | Whether this resource is aggregated |
| Control | Mandatory, 1..1 |
| Type | boolean |
| Constraint.element.resource.profile |
| Definition | Reference to a Resource Profile |
| Control | Optional, 0..1 |
| Type | uri |
| Comments | The reference might be a simple name in the form #[name], which is a reference to another named constraint in a resource - where the resource contains more than one constraint, or a RUL which is a reference to a resource Profile |
| Constraint.element.valueSet |
| Definition | Value set id (only if coded) |
| Control | Optional, 0..1 |
| Type | string |
| Constraint.element.value |
| Control | Optional, 0..* |
| Constraint.element.value.name |
| Definition | Reference to another element by element.name |
| Control | Conditional, 0..1: Either a name or a fixed value is required |
| Type | string |
| Constraint.element.value.[type] |
| Definition | Fixed value: [as defined for type] |
| Control | Conditional, 0..1: Either a name or a fixed value is required |
| Type | * |
This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.01 generated on Mon, May 14, 2012 09:48+1000.