The following table describes the primitive types that are used in this specification. Primitive types are those with only a value, and no additional elements as children (though, like all types, they have extensions). See also the Examples.

Todo: is it possible to impose an upper absolute limit on a base64Binary (for denial of service reasons, like on string)?

instant

An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime

xs:dateTime

A JSON string - an xs:dateTime

Note: This type is for system times, not human times (see date and dateTime below).

date

A date, or partial date (e.g. just year or year + month) as used in human communication. There is no time zone. Dates SHALL be valid dates

union of xs:date, xs:gYearMonth, xs:gYear

A JSON string - a union of xs:date, xs:gYearMonth, xs:gYear

Regex: -?[0-9]{4}(-(0[1-9]|1[0-2])(-(0[0-9]|[1-2][0-9]|3[0-1]))?)?

dateTime

A date, date-time or partial date (e.g. just year or year + month) as used in human communication. If hours and minutes are specified, a time zone SHALL be populated. Seconds must be provided due to schema type constraints but may be zero-filled and may be ignored. Dates SHALL be valid dates. The time "24:00" is not allowed

A time during the day, with no date specified (can be converted to a Duration since midnight). Seconds must be provided due to schema type constraints but may be zero-filled and may be ignored. The time "24:00" is not allowed, and neither is a time zone

xs:time

A JSON string - an xs:time

Regex: ([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?

code

Indicates that the value is taken from a set of controlled strings defined elsewhere (see Using codes for further discussion). Technically, a code is restricted to a string which has at least one character and no leading or trailing whitespace, and where there is no whitespace other than single spaces in the contents

Any combination of upper or lower case ASCII letters ('A'..'Z', and 'a'..'z', numerals ('0'..'9'), '-' and '.', with a length limit of 64 characters. (This might be an integer, an un-prefixed OID, UUID or any other identifier pattern that meets these constraints.)

xs:string

JSON string

Regex: [A-Za-z0-9\-\.]{1,64}

markdown

A string that may contain markdown syntax for optional processing by a markdown presentation engine

xs:string

JSON string

unsignedInt

Any non-negative integer (e.g. >= 0)

xs:nonNegativeInteger

JSON number

Regex: [0]|([1-9][0-9]*)

positiveInt

Any positive integer (e.g. >= 1)

xs:positiveInteger

JSON number

Regex: +?[1-9][0-9]*

Notes:

For all the types, the XML, JSON and Turtle representations of the primitive values are the same except for different escaping in XML and JSON

The regexes may allow a broader set of values than are actually valid (e.g. leap years) so additional validation is needed

The regexes should be qualified with start of string and end of string anchors based on the regex implementation used (e.g. caret '^' and dollar-sign '$' for JavaScript, POSIX, XML and XPath; '\A' and '\Z' for .NET, Java, Python and others; please verify these definitions with the regex implementation used).

In object code, implementations that might meet this constraint are GMP implementations or equivalents to Java BigDecimal that implement arbitrary precision, or a combination of a (64 bit) floating point value with a precision field

Note that there is no absolute limit to the magnitude of the value, though large and/or highly precise values are extremely rare in medicine. One element where highly precise decimals may be encountered is the Location coordinates

About the id datatype:

Ids are case sensitive. UUIDs SHALL be sent using lowercase letters

The ID type includes identifiers consistent with ISO 18232 , but also includes other identifier formats as well, and is not case insensitive like ISO 18232.

In a typical FHIR URL, like http://example.com/fhir/Patient/1234, the last part "1234" (highlighted in red) is the part that is an id datatype

A full UUID is a uri, not an id. UUIDs in URIs SHALL also be represented in lowercase (urn:uuid:59bf0ef4-e89c-4628-9b51-12ae3fdbe22b)

About the markdown datatype:

Systems are not required to have markdown support, and there is considerable variation in markdown syntax, so the content of a string should be readable without markdown processing, per markdown philosophy

Markdown content should not contain Unicode character points below 32, except for u0009 (horizontal tab), u0010 (carriage return) and u0013 (line feed). Todo: is there any reason not to make this a SHALL?

STU Note: It is likely that FHIR will change to require/recommend CommonMark in Release 4.

2.26.0.1.1 Representations in XML, JSON, and Turtle

All elements using these primitive types may have one or more of a value as described above, an internal identity (e.g. xml:id), and extensions. For an example, take an element of name "count" and type "integer".

XML

The value is represented in XML as an attribute named "value":

The full representation, with id, extensions and value:

JSON

In JSON, for convenience, the value is represented as the property itself:

"count" : 2

The full representation, with id, extensions and value, showing the id and extensions in the sibling property:

For additional details, see the XML, JSON and Turtle format definitions. When the value is missing, and there are no extensions, the element is not represented at all. This means that in xml, attributes are never present with a length of 0 (value=""), and properties are never a 0 length string or null in JSON ("name" : "" is not valid). (note: there is one specific use of the null in the JSON representation).

According to XML schema, leading and trailing whitespace in the value attribute is ignored for the types boolean, integer, decimal, base64Binary, instant, uri, date, dateTime, oid, and uri. Note that this means that the schema aware XML libraries give different attribute values to non-schema aware libraries when reading the XML instances. For this reason, the value attribute for these types SHOULD not have leading and trailing spaces. String values should only have leading and trailing spaces if they are part of the content of the value. In JSON and Turtle whitespace in string values is always significant. Primitive types other than string SHALL NOT have leading or trailing whitespace.

2.26.0.2 Complex Types

In XML, these types are represented as XML Elements with child elements with the name of the defined elements of the type. The name of the element is defined where the type is used. In JSON, the data type is represented by an object with properties named the same as the XML elements. Since the JSON representation is almost exactly the same, only the first example has an additional explicit JSON representation.

Complex data types may be "profiled". A Structure Definition or type "constraint" makes a set of rules about which elements SHALL have values and what the possible values are.

2.26.0.3 Attachment

This type is for containing or referencing attachments - additional data content defined in other formats. The most common use of this type is to include images or reports in some report format such as PDF. However it can be used for any data that has a MIME type.

The actual content of an Attachment can be conveyed directly using the data element or a URL reference can be provided. If both are provided, the reference SHALL point to the same content as found in the data. The reference can never be reused to point to some different data (i.e. the reference is version specific). The URL reference SHALL point to a location that resolves to actual data; some URIs such as cid: meet this requirement. If the URL is a relative reference, it is interpreted in the same way as a resource reference.

The contentType element SHALL always be populated when an Attachment contains data, and MAY be populated when there is a url. It can include charset information and other mime type extensions as appropriate. If there is no character set in the contentType then the correct course of action is undefined, though some media types may define a default character set and/or the correct character set may be able to be determined by inspection of the content.

The hash is included so that applications can verify that the content returned by the URL has not changed. The hash and size relate to the data before it is represented in base64 form.

In many cases where Attachment is used, the cardinality is >1. A valid use of repeats is to convey the same content in different mime types and languages. Guidance on the meaning of repeating elements SHALL be provided in the definition of the repeating resource element or extension that references this type. The language element describes the language of the attachment using the codes defined in BCP 47 .

Constraints

att-1: It the Attachment has data, it SHALL have a contentType (expression : data.empty() or contentType.exists())

If neither data nor a URL is provided, the value should be understood as an assertion that no content for the specified mimeType and/or language is available for the combination of language and contentType.

The context of use may frequently make rules about the kind of attachment (and therefore, the kind of mime types) that can be used.

The meaning of the Coding is defined by the code. The system provides the source of the definition of the code, along with an optional version reference. The display is a human display for the text defined by the system - it is not intended for computation.

The system is a URI that references the code system that defines the code. Choosing the correct system is important; for more information about the code system URI, read Managing Terminology System URIs. The system URI SHALL NOT contain a reference to a value set (e.g. ValueSet.url). If the code is taken from a CodeSystem resource, CodeSystem.url is the correct value for the system uri. Resolvable URLs are generally preferred by implementers over non-resolvable URNs, particularly opaque URNs such as OIDs (urn:oid:) or UUIDs (urn:uuid:).

A code system version may also be supplied. If the meaning of codes within the code system is consistent across releases, this is not required. The version SHOULD be exchanged when the system does not maintain consistent definitions across versions. Note that the following systems SHOULD always have a version specified:

National releases of SNOMED CT (consistency of definitions varies amongst jurisdictions, and some jurisdictions may make their own rules on this)

Various versions of ICD (note: the major releases are labeled as different code systems altogether, but there is variation within versions)

If present, the code SHALL be a syntactically correct symbol as defined by the system. In some code systems such as SNOMED CT, the symbol may be an expression composed of other predefined symbol (e.g. post-coordination). Note that codes are case sensitive unless specified otherwise by the code system. The display is a text representation of the code defined by the system and is used to display the meaning of the code by an application that is not aware of the system.

Where the code system defines multiple possible display strings, one of these SHALL be used in display. If one is labeled as preferred, it SHOULD be used. If the code system does not define a text representation (e.g. SNOMED CT Expressions) then display cannot be populated, and the meaning of the code won't be accessible to systems that don't understand the code expression.

In some cases, the system may not be known - only the code is known. In this case, no useful processing of the code may be performed unless the system can be safely inferred by the context. This practice should be avoided where possible, as information sharing in a wider context is very likely to arise eventually, and codes cannot be used in the absence of a known system.

If the system is present, and there is no code, then this is understood to mean that there is no suitable code in the system in which to represent the code.

If two codings have the same system, version and code then they have the same meaning. If the version information is missing, or the system, version or the code elements differ, then how the codes are related can only be determined by consulting the definitions of the system(s) and any mappings available.

A coding may be marked as a "userSelected" if a user selected the particular coded value in a user interface (e.g. the user selects an item in a pick-list). If a user selected coding exists, it is the preferred choice for performing translations etc.

And adidas Sneakers Footwear Low Tops Originals Constraints

The context of use (as defined in the resource or applicable profile) usually makes rules about what codes and systems are allowed or required in a particular context by binding the element to a value set.

CodeableConcept: a text description and/or a list of Codings (i.e. a list of references to codes defined by code systems)

The Coding data type corresponds to the simple case of selecting a single code from a code list. However this type is rarely used in the FHIR specifications; long experience with exchanging coded values in HL7 shows that in the general case, systems need to able to exchange multiple translation codes, and/or an original text.

The Coding data type is used directly when there is certainty that the value must be selected directly from one of the available codes, and the list of possible codes is agreed to by all participants. This is not usually the case in the context of FHIR - general interoperability - so Coding is mostly used in extensions, which are usually intended to be defined for a well-controlled context of use.

2.26.0.5 CodeableConcept

A CodeableConcept represents a value that is usually supplied by providing a reference to one or more terminologies or ontologies, but may also be defined by the provision of text. This is a common pattern in healthcare data.

Each coding is a representation of the concept as described above. The concept may be coded multiple times in different code systems (or even multiple times in the same code systems, where multiple forms are possible, such as with SNOMED CT). The different codings may have slightly different granularity due to the differences in the definitions of the underlying codes. There is no meaning associated with the ordering of coding within a CodeableConcept. A typical use of CodeableConcept is to send the local code that the concept was coded with, and also one or more translations to publicly defined code systems such as LOINC or SNOMED CT. Sending local codes is useful and important for the purposes of debugging and integrity auditing.

Whether or not coding elements are present, the text is the representation of the concept as entered or chosen by the user, and which most closely represents the intended meaning of the user or concept. Very often the text is the same as a display of one of the codings. One of the codings may be flagged as the userSelected - the code or concept that the user actually selected directly. When none of the coding elements is marked as userSelected, the text (if present) is the preferred source of meaning.

Constraints

The context of use usually makes rules about what codes and systems are allowed or required in a particular context by binding the element to a value set.

The value contains the numerical value of the quantity, including an implicit precision. If no comparator is specified, the value is a point value (i.e. '='). The comparator element can never be ignored.

The unit element contains a displayable unit that defines what is measured. The unit may additionally be coded in some formal way using the code and the system (see Coding for further information about how to use the system element).

If the unit can be coded in UCUM and a code is provided, it SHOULD be a UCUM code. If a UCUM unit is provided in the code, then a canonical value can be generated for purposes of comparison between quantities. Note that the unit element will often contain text that is a valid UCUM unit, but it cannot be assumed that the unit actually contains a valid UCUM unit.

Constraints

qty-3: If a code for the unit is present, the system SHALL also be present (expression : code.empty() or system.exists())

The context of use may frequently define what kind of measured quantity this is and therefore what kind of unit can be used. The context of use may additionally require a code from a particular system. The context of use may also restrict the values for the value or range.

2.26.0.6.1 Defined Variations on Quantity

There are several additional data types that are specializations of Quantity that only introduce new restrictions on the existing elements defined as part of the Quantity data type:

Type Name

Rules

Formal Definitions

Age

age-1: There SHALL be a code if there is a value and it SHALL be an expression of time. If system is present, it SHALL be UCUM. If value is present, it SHALL be positive. (expression : (code or value.empty()) and (system.empty() or system = %ucum) and (value.empty() or value > 0))

cnt-3: There SHALL be a code with a value of "1" if there is a value and it SHALL be an expression of length. If system is present, it SHALL be UCUM. If present, the value SHALL a whole number. (expression : (code or value.empty()) and (system.empty() or system = %ucum) and (code.empty() or code = '1') and (value.empty() or value.toString().contains('.').not()))

dis-1: There SHALL be a code if there is a value and it SHALL be an expression of length. If system is present, it SHALL be UCUM. (expression : (code or value.empty()) and (system.empty() or system = %ucum))

drt-1: There SHALL be a code if there is a value and it SHALL be an expression of time. If system is present, it SHALL be UCUM. (expression : code.exists() implies ((system = %ucum) and value.exists()))

mny-1: There SHALL be a code if there is a value and it SHALL be an expression of currency. If system is present, it SHALL be ISO 4217 (system = "urn:iso:std:iso:4217" - currency). (expression : (code or value.empty()) and (system.empty() or system = 'urn:iso:std:iso:4217'))

The unit and code/system elements of the low or high elements SHALL match. If the low or high elements are missing, the meaning is that the low or high boundaries are not known and therefore neither is the complete range.

The comparator flag on the low or high elements cannot be present. Note that the Range type should not be used to represent out of range measurements: A quantity type with the comparator element should be used instead.

The low and the high values are inclusive, and are assumed to have arbitrarily high precision; e.g. the range 1.5 to 2.5 includes 1.50, and 2.50 but not 1.49 or 2.51.

Constraints

rng-2: If present, low SHALL have a lower value than high (expression : low.empty() or high.empty() or (low <= high))

A ratio of two Quantity values - a numerator and a denominator+ Numerator and denominator SHALL both be present, or both are absent. If both are absent, there SHALL be some extension presentElements defined in Ancestors: id, extension

A ratio of two Quantity values - a numerator and a denominator+ Numerator and denominator SHALL both be present, or both are absent. If both are absent, there SHALL be some extension presentElements defined in Ancestors: id, extension

Common factors in the numerator and denominator are not automatically cancelled out. The Ratio data type is used for titers (e.g. "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numbers" - for example blood pressure measurements (e.g. "120/60") are not ratios. In addition, ratios are used where common factors in the numerator and denominator do not cancel out. The most common example of this is where the ratio represents a unit cost, and the numerator is a currency (e.g. 50/$10).

A proper ratio has both a numerator and a denominator; however these are not mandatory in order to allow an invalid ratio with an extension with further information.

Constraints

rat-1: Numerator and denominator SHALL both be present, or both are absent. If both are absent, there SHALL be some extension present (expression : (numerator.empty() xor denominator.exists()) and (numerator.exists() or extension.exists()))

The context of use may require particular types of Quantity for the numerator or denominator.

2.26.0.9 Period

A period specifies a range of times. The context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the period applies (e.g. "give to the patient between 2 and 4 pm on 24-Jun 2013").

If the start element is missing, the start of the period is not known. If the end element is missing, it means that the period is ongoing, or the start may be in the past, and the end date in the future, which means that period is expected/planned to end at the specified time

The end value includes any matching date/time. For example, the period 2011-05-23 to 2011-05-27 includes all the times from the start of the 23rd May through to the end of the 27th of May.

2.26.0.10 SampledData

Data that comes from a series of measurements taken by a device, which may have upper and lower limits. The data type also supports more than one dimension in the data.

A SampledData provides a concise way to handle the data produced by devices that sample a particular physical state at a high frequency. A typical use for this is for the output of an ECG or EKG device. The data type includes a series of raw decimal values (which are mostly simple integers), along with adjustments for scale and factor. These are interpreted such that

The digits are a set of decimal values separated by a single space (Unicode character u20). In addition to decimal values, the special values "E" (error), "L" (below detection limit) and "U" (above detection limit) can also be used. If there is more than one dimension, the different dimensions are interlaced - all the data points for a particular time are represented together. The default value for factor is 1.

2.26.0.11 Identifier

A numeric or alphanumeric string that is associated with a single object or entity within a given system. Typically, identifiers are used to connect content in resources to external content available in other frameworks or protocols. Identifiers are associated with objects, and may be changed or retired due to human or system process and errors.

The value SHALL be unique within the defined system and have a consistent meaning wherever it appears. Both system and value are always case sensitive.

The system is a URI that defines a set of identifiers (i.e. how the value is made unique). It might be a specific application or a recognized standard/specification for a set or identifiers or a way of making identifiers unique. FHIR defines some useful or important system URIs directly. Here are some example identifier namespaces:

http://hl7.org/fhir/sid/us-ssn for United States Social Security Number (SSN) values

urn:ietf:rfc:3986 for when the value of the identifier is itself a globally unique URI

If the system is a URL, it SHOULD resolve. Resolution might be to a web page that describes the identifier system and/or supports look-up of identifiers. Alternatively, it could be to a NamingSystem resource instance. Resolvable URLs are generally preferred by implementers over non-resolvable URNs, particularly opaque URNs such as OIDs (urn:oid:) or UUIDs (urn:uuid:). If used, OIDs and UUIDs may be registered in the HL7 OID registry and SHOULD be registered if the content is shared or exchanged across institutional boundaries.

It is up to the implementer organization to determine an appropriate URL or URN structure that will avoid collisions and to manage that space (and the resolvability of URLs) over time.

Note that the scope of a given identifier system may extend beyond identifiers that might be captured by a single resource. For example, some systems might draw all "order" identifiers from a single namespace, though some might be used on MedicationRequest while others would appear on ProcedureRequest.

If the identifier value itself is naturally a globally unique URI (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986", and the URI is in the value (OIDs and UUIDs using urn:oid: and urn:uuid: - see examples).

In some cases, the system may not be known - only the value is known (e.g. a simple device that scans a barcode), or the system is known implicitly (simple exchange in a limited context, often driven by barcode readers). In this case, no useful matching may be performed using the value unless the system can be safely inferred by the context. Applications should provide a system wherever possible, as information sharing in a wider context is very likely to arise eventually, and values without a system are inherently limited in use.

In addition to the system (which provides a uniqueness scope) and the value, identifiers may also have a type, which may be useful when a system encounters identifiers with unknown system values. Note, however, that the type of an identifier is not a well-controlled vocabulary with wide variations in practice. The type deals only with general categories of identifiers and SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to variations in common usage.

The assigner is used to indicate what registry/state/facility/etc. assigned the identifier. As a Reference, the assigner can include just a text description in the display.

2.26.0.12 HumanName

Names may be changed or repudiated. People may have different names in different contexts. Names may be divided into parts of different type that have variable significance depending on context, though the division into parts is not always significant. With personal names, the different parts may or may not be imbued with some implicit meaning; various cultures associate different importance with the name parts and the degree to which systems SHALL care about name parts around the world varies widely.

This table summarizes where common parts of a person's name are found.

Name

Example

Destination / Comments

Surname

Smith

Family Name

First name

John

Given Name

Title

Mr

Prefix

Middle Name

Samuel

Subsequent Given Names

Patronymic

bin Osman

Family Name

Multiple family names

Carreño Quiñones

Family Name. See note below about decomposition of family name

Initials

Q.

Given Name as initial ("." recommended)

Nick Name

Jock

Given name, with Use = common

Qualifications

PhD

Suffix

Honorifics

Senior

Suffix

Voorvoegsel / Nobility

van Beethoven

Family Name. See note below about decomposition of family name

For further information, including all W3C International Examples , consult the examples. Note: Implementers should read the name examples for a full understanding of how name works.

The multiple given parts and family name combine to form a single name. Where a person has alternate names that may be used in place of each other (e.g. Nicknames, Aliases), these are different instances of HumanName.

The text element specifies the entire name as it should be represented. This may be provided instead of or as well as specific parts, and can be built from the parts, though the correct order of assembly of the parts is culture dependent: the order of the parts within a given part type has significance and SHALL be observed. The appropriate order between family name and given names depends on culture and context of use. Note that there is an extension for the few times name assembly order is not fixed by the culture.

The given name parts may contain whitespace, though generally they don't. Initials may be used in place of the full name if that is all that is recorded. Systems that operate across cultures should generally rely on the text form for presentation, and use the parts for index/search functionality. For this reasons, applications SHOULD populate the text element for future robustness.

In some cultures (e.g. German, Dutch, Spanish, Portuguese), family names are complex and composed of various parts that may need to be managed separately, e.g. they have differing significance for searching. In these cases, the full family name is populated in family, and a decomposition of the name can be provided using the family extensions own-name, own-prefix, partner-name, partner-prefix, fathers-family and mothers-family.

For robust search, servers should search the parts of a family name independently. E.g. Searching either Carreno or Quinones should match a family name of "Carreno Quinones". HL7 affiliates may make more specific recommendations about how search should work in their specific culture.

2.26.0.13 Address

An address expressed using postal conventions (as opposed to GPS or other location definition formats). This data type may be used to convey addresses for use in delivering mail as well as for visiting locations which might not be valid for mail delivery. There are a variety of postal address formats defined around the world.

The text element specifies the entire address as it should be represented. This may be provided instead of or as well as the specific parts. Applications updating an address SHALL ensure either that the text and the parts are in agreement, or that only one of the two is present.

If capturing a phone, fax or similar contact point, the value should be a properly formatted telephone number according to ITU-T E.123 . However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, pager, and email addresses are not handled as formal URLs. For other kinds of contact points, the system is "other" and the value SHOULD be a URL so that its use can be determined automatically. Typical URL schemes used in the value are http(s): for web addresses, and URL schemes for various kinds of messaging systems. If the value is not a URL, then human interpretation will be required.

The rank element can be used to specify a preference for the order in which a set of contacts is used. Contacts are ranked with lower values coming before higher values. Note that rank does not necessarily follow the order in which the contacts are represented in the instance.

Constraints

cpt-2: A system is required if a value is provided. (expression : value.empty() or system.exists())

2.26.0.15 Timing

Specifies an event that may occur multiple times. Timing schedules are used for specifying when events are expected or requested to occur, and may also be used to represent a schedule that was followed for past events. A Timing schedule can be a list of events and/or criteria for when the event happens, which can be expressed in a structured form and/or as a code. When both event and a repeating specification are provided, the list of events should be understood as an interpretation of the information in the repeat structure.

When the event is to occur+ If there's an offset, there must be a when (and not C, CM, CD, CV)+ period SHALL be a non-negative value+ If there's a periodMax, there must be a period+ If there's a durationMax, there must be a duration+ If there's a countMax, there must be a count+ if there's a duration, there needs to be duration units+ If there's a timeOfDay, there cannot be be a when, or vice versa+ if there's a period, there needs to be period units+ duration SHALL be a non-negative value

When the event is to occur+ If there's an offset, there must be a when (and not C, CM, CD, CV)+ period SHALL be a non-negative value+ If there's a periodMax, there must be a period+ If there's a durationMax, there must be a duration+ If there's a countMax, there must be a count+ if there's a duration, there needs to be duration units+ If there's a timeOfDay, there cannot be be a when, or vice versa+ if there's a period, there needs to be period units+ duration SHALL be a non-negative value