Snapshot 3: Connectathon 32 Base

This page is part of the FHIR Specification (v5.0.0-snapshot3: R5 Snapshot #3, to support Connectathon 32). 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: R5 R4B

2.1.6.1 UML definition

FHIR Infrastructure icon Work GroupMaturity Level: NormativeStandards Status: Normative

2.1.6.1.1 UML

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
NameA Documentationelement : [type] [0..*] DocumentationnameB : CodeableConcept [0..1] « Value Set Description (Strength=Preferred)Value Set Name? » NameC Documentationvalue[x] : Type [0..1] « Type1|Type2|Type3 » Docuementationreference : Reference [0..1] « Resource1|Resource2 » DocumentationnameC [0..1]

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:

BaseElementUnique id for the element within a resource (for internal references). This may be any string value that does not contain spacesid : string [0..1]May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extensionextension : Extension [0..*]BackboneElementMay be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself) (this element modifies the meaning of other elements)modifierExtension : Extension [0..*]DataTypeResourceThe logical id of the resource, as used in the URL for the resource. Once assigned, this value never changesid : id [0..1]The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resourcemeta : Meta [0..1]A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc (this element modifies the meaning of other elements)implicitRules : uri [0..1]The base language in which the resource is writtenlanguage : code [0..1] « null (Strength=Preferred)CommonLanguages? »DomainResourceA human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safetytext : Narrative [0..1]These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, nor can they have their own independent transaction scope. This is allowed to be a Parameters resource if and only if it is referenced by a resource that provides context/meaningcontained : Resource [0..*]May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extensionextension : Extension [0..*]May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself) (this element modifies the meaning of other elements)modifierExtension : Extension [0..*]PrimitiveTypeBackboneTypeMay be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself) (this element modifies the meaning of other elements)modifierExtension : Extension [0..*]CanonicalResource «Interface»An absolute URI that is used to identify this {{title}} when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which an authoritative instance of this {{title}} is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the {{title}} is stored on different serversurl : uri [0..1]A formal identifier that is used to identify this {{title}} when it is represented in other formats, or referenced in a specification, model, design or an instanceidentifier : Identifier [0..*]The identifier that is used to identify this version of the {{title}} when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the {{title}} author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequenceversion : string [0..1]Indicates the mechanism used to compare versions to determine which is more currentversionAlgorithm[x] : DataType [0..1] « string|Coding; null (Strength=Extensible) VersionAlgorithm+ »A natural language name identifying the {{title}}. This name should be usable as an identifier for the module by machine processing applications such as code generationname : string [0..1] « This element has or is affected by some invariantsC »A short, descriptive, user-friendly title for the {{title}}title : string [0..1]The status of this {{title}}. Enables tracking the life-cycle of the content (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)PublicationStatus! »A Boolean value to indicate that this {{title}} is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usageexperimental : boolean [0..1]The date (and optionally time) when the {{title}} was last significantly changed. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the {{title}} changesdate : dateTime [0..1]The name of the organization or individual responsible for the release and ongoing maintenance of the {{title}}publisher : string [0..1]Contact details to assist a user in finding and communicating with the publishercontact : ContactDetail [0..*]A free text natural language description of the {{title}} from a consumer's perspectivedescription : markdown [0..1]The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate {{title}} instancesuseContext : UsageContext [0..*]A legal or geographic region in which the {{title}} is intended to be usedjurisdiction : CodeableConcept [0..*] « null (Strength=Extensible)JurisdictionValueSet+ »Explanation of why this {{title}} is needed and why it has been designed as it haspurpose : markdown [0..1]A copyright statement relating to the {{title}} and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the {{title}}copyright : markdown [0..1]A short string (<50 characters), suitable for inclusion in a page footer that identifies the copyright holder, effective period, and optionally whether rights are resctricted. (e.g. 'All rights reserved', 'Some rights reserved')copyrightLabel : string [0..1]MetadataResource «Interface»The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usageapprovalDate : date [0..1]The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval datelastReviewDate : date [0..1]The period during which the {{title}} content was or is planned to be in active useeffectivePeriod : Period [0..1]Descriptive topics related to the content of the {{title}}. Topics provide a high-level categorization as well as keywords for the {{title}} that can be useful for filtering and searchingtopic : CodeableConcept [0..*] « null (Strength=Example)DefinitionTopic?? »An individiual or organization primarily involved in the creation and maintenance of the {{title}}author : ContactDetail [0..*]An individual or organization primarily responsible for internal coherence of the {{title}}editor : ContactDetail [0..*]An individual or organization primarily responsible for review of some aspect of the {{title}}reviewer : ContactDetail [0..*]An individual or organization responsible for officially endorsing the {{title}} for use in some settingendorser : ContactDetail [0..*]Related artifacts such as additional documentation, justification, dependencies, bibliographic references, and predecessor and successor artifactsrelatedArtifact : RelatedArtifact [0..*]

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 it's 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: