This page is part of the FHIR Specification v6.0.0-ballot1: Release 6 Ballot (1st Draft) (see Ballot Notes). The current version is 5.0.0. For a full list of available versions, see the Directory of published versions
The UML diagrams represent the Resource and Type defined in this specification in UML.
Each type is represented as a class with a name and an ancestor class (except for Base, which has no ancestor).
In addition, types may be marked as abstract, or assigned stereotypes that describe how they used.
Classes also have a zero or
more attributes defined, where each attribute has the following properties:
name: the name of the attribute
type: the type of the attribute - either another type defined in the speification, or (for primitive types) a type from XML Schema
[cardinality]: [min..max] control over the attribute cardinality. Attributes with Max cardinality >1 (usually *) are ordered, though
the meaning of the order might not be known or defined
« stereotypes »: these provide additional detail about the element - see below
In addition, classes have zero or more associations, which are always aggregations, and have the following properties:
name: the name of the association (which is the name of the element that represents it in XML/JSON)
[cardinality]: [min..max] control over the association cardinality. Associations with Max cardinality >1 (usually *) are ordered, though
the meaning of the order might not be known or defined
The elements and the datatypes are hyperlinks to the formal definitions of the parts.
Note that the order of elements in XML (the only serialization where order is required to be correct)
cannot be inferred from the UML diagram - the attributes will be in the order presented, but the
order in which the associations are serialized, which are interspersed with the attributes, cannot be determined.
Also, it cannot be determined whether a UML property becomes an element or an attribute in the XML representation.
2.1.6.1.2 Abstract Classes
Some resources and types are labeled as abstract. Such classes are never instantiated with being specialized.
This is the usual meaning of an abstract class in UML. In the diagrams, a class that is abstract has the class name in italics.
This class diagram includes all the abstract types:
2.1.6.1 Stereotypes - Class
This specification uses a number of stereotypes to further define the types and resources.
The following stereotypes are used on classes.
2.1.6.1.1 Interface
Some of the abstract types are labeled with the stereotype «Interface». This indicates that in addition
to being abstract, the definitions associated with the class have no implementation. As such:
There is no implementation of the interface described by the definition
Any classes that implement the interface redeclare any attributes and associations that are on the interface, and gives them an order
Such re-declarations will be consistent with the interface but may be a subset of the value domain e.g. the cardinality of an attribute may be 0..* on the interface, and 0..1 on a particular resource
In addition, the resource might not implement the attribute at all - this is equivalent to constraining the attribute to a cardinality of 0..0 - not used with this resource
Since interfaces support both read and write, the interface is described using attributes not operations
Interfaces that inherit from an abstract resource (e.g. DomainResource)
can only be implemented by Resources that also inherit from the same abstract resource
The interface resources also define search parameters, invariants and other information about the resources that are all inherited by the resources that implement these interfaces
Rules for referring to interface types:
StructureDefinition.context.expression: If an extension has a context
which is an interface, All resources that implement the interface become valid contexts.
If the context is a path within the interface, the resource must have that path.
SearchParameter.base: Interfaces can be referenced here, and if they are, the search parameter
applies to all the implementing resources that a system supports, and appear in the list of
search parameters that implement the interface (though note that implementing any search
parameters is at the discretion of the server)
Reference.type: literal references cannot refer to interfaces (or abstract resources)
ElementDefinition.type.code: The stated type of an element cannot be an interface (but it can be an abstract resource)
ElementDefinition.type.profile: If a profile references an interface, then all
resources that implement the interface are valid resources (e.g. on Bundle.entry.resource)
ElementDefinition.type.target:- yes. If a profile references an interface, then all
resources that implement the interface are valid target resources
Notes for implementers:
The interfaces may be treated as part of a single hierarchy, though allowance will have to be
made for cardinality changes when interfaces are implemented. This specification itself does
not define any multiple inheritance paths
Some reference implementations may wish to represent the interfaces as classes internally - the
best way to handle this depends on language features
This use of interface is well established in the UML/Object-Orientated Programming concept space, and
differs from APIs, where APIs are sometimes called interfaces and always have implementations.
2.1.6.1.2 Pattern
Some of types are labeled with the stereotype «Pattern». This indicates that in addition
to being abstract, and potentially an interface, classes that do follow the interface do so loosely. As such:
There is no direct implementation of the patterns
The relationship between the attributes and associations may be indirect - e.g. attributes may be renamed, restructured, or have different value domains
Such patterns are there primarily to provide document general design intentions, which are subject to ongoing harmonization with observed real-world requirements
The relationship between the patterns and the resources that follow them is found in the mappings for the resources
Notes for implementers:
It is possible to implement these patterns using code generation as interfaces, but in general implementers should expect to write code manually to implement the mappings, and have arrangements for dealing with differences such as adding 'canDoX' to the implementation of the pattern
2.1.6.1 Stereotypes - Attributes
There are three stereotypes for attributes, both of which constrain the value domain of the assigned datatype. These three
stereotypes can be differentiated by examining the contents of the stereotype.
Note that where these stereotypes are allowed, they are usually present and populated.
2.1.6.1.1 Type Choice
If the datatype assigned to an attribute is abstract, then a stereotype may be provided that
indicates which concrete sub-types are allowed to be used for this particular element. If this stereotype is provided, only the specified
types are allowed. Note: as such, this is equivalent to an OCL constraint on the attribute.
The format of this stereotype is a list of types defined within this specification (concrete specializations of DataType)
separated by the | character.
2.1.6.1.2 Target Reference Type
If the datatype assigned to an attribute is a reference to another resource (one of
Reference, canonical or CodeableReference),
then a stereotype may be provided that indicates which kinds of resources the references are allowed to refer to. If this stereotype is provided, only the specified
resources are allowed to be referenced. Note: as such, this is conceptually equivalent to an OCL constraint on the attribute, but the rules can only be evaluated by
fetching the target of the reference from the specified URL and examining its content.
The format of this stereotype is a list of resource types defined within this specification (concrete specializations of Resource)
separated by the | character.
2.1.6.1.3 Vocabulary Binding
If the datatype associated with the attribute is one of the datatypes that can be bound to a value set,
then a stereotype may be provided that restricts the codes that may be present in the attribute. If this stereotype is provided, the rules as defined
by the binding must be followed. Note: there is no OCL equivalent for this stereotype.
This stereotype has two parts: the value set name (which is a link to the value set),
and a symbol that denotes the strength of the binding: