DSTU2
This page is part of the FHIR Specification (v1.0.2: DSTU 2). 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 R4 R3 R2
| FHIR Infrastructure | Maturity Level: 3 | Ballot Status: DSTU 2 |
The FHIR specification defines a set of data types that are used for the resource elements. There are two categories of data types: simple / primitive types, which are single elements, and complex types, which are re-usable clusters of elements. This page describes the data types. See also the Examples, Detailed Descriptions and Mappings.
Table of Contents
| Primitive Types |
Complex Types |
White = abstract type. Light blue - types. Light Pink - Profile on Type. The data types are also available as a W3C Schema.
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).
| Primitive Types | |||
| FHIR Name | Value Domain | XML Representation | JSON representation |
|---|---|---|---|
| boolean | true | false | xs:boolean, except that 0 and 1 are not valid values | JSON boolean (true or false) |
| integer | A signed 32-bit integer (for larger values, use decimal) | xs:int, except that leading 0 digits are not allowed | JSON number (with no decimal point) |
| string | A sequence of Unicode characters | xs:string | JSON String |
| Note that strings SHALL NOT exceed 1MB in size | |||
| decimal | Rational numbers that have a decimal representation. See below about the precision of the number | xs:decimal, except that decimals may not use exponents, and leading 0 digits are not allowed | A JSON number, except that exponents are not allowed |
| uri | A Uniform Resource Identifier Reference (RFC 3986 |
xs:anyURI | A JSON string - a URI |
| URIs can be absolute or relative, and may have an optional fragment identifier | |||
| base64Binary | A stream of bytes, base64 encoded (RFC 4648 |
xs:base64Binary | A JSON string - base64 content |
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 | union of xs:dateTime, xs:date, xs:gYearMonth, xs:gYear | A JSON string - a union of xs:dateTime, 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])(T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)))?)?)? | |||
| time | 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]+)? | |||
Notes:
All elements using these primitive types have some combination of value as described above, an internal identity (e.g. xml:id), and extensions. The value is represented in XML as an attribute named "value":
<count value="2"/>
and as the value of the property in JSON:
"count" : 2
For additional details, including how the internal identity and extensions are represented, see the XML and JSON formats. When the value is missing, it is not represented in the instance; the XML value attribute or the JSON property are 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, whitespace in string values is always significant. Primitive types other than string SHALL NOT have leading or trailing whitespace.
In addition to the base primitive types, a few additional primitive types are defined as restrictions on one of the other primitive types.
| FHIR Name | Base FHIR Type | Description |
|---|---|---|
| code | string | 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 regex: [^\s]+([\s]+[^\s]+)* |
| oid | uri | An OID represented as a URI (RFC 3001 regex: urn:oid:[0-2](\.[1-9]\d*)+ |
| id | string | 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.)
regex: [A-Za-z0-9\-\.]{1,64} |
| markdown | string | A string that may contain markdown syntax for optional processing by a markdown presentation engine |
| unsignedInt | int | Any non-negative integer (e.g. >= 0) regex: [0-9]+ |
| positiveInt | int | Any positive integer (e.g. > 0) regex: [1-9][0-9]* |
Some additional notes about the id datatype:
http://example.com/fhir/Patient/1234, the last part "1234" (highlighted in red) is the part that is an id datatypeuri, not an id. UUIDs in URIs SHALL also be represented in lowercase (urn:uuid:59bf0ef4-e89c-4628-9b51-12ae3fdbe22b)
Some additional notes about the markdown datatype:
DSTU Note: CommonMark
is a new arrival but may gain sufficient impetus to be preferred in a future version.
Feedback is welcome here
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. Any of the XML elements may have an id attribute. In JSON, the data type is represented by an object with properties named the same as the XML elements. The JSON representation is almost exactly the same, so only the first example has an additional 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.
UML Diagrams of the Data types
See also Examples, Detailed Descriptions and Mappings.
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.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Content in a format defined elsewhere It the Attachment has data, it SHALL have a contentType | ||
| Σ | 0..1 | code | Mime type of the content, with charset etc. MimeType | |
| Σ | 0..1 | code | Human language of the content (BCP-47) Language | |
| Σ | 0..1 | base64Binary | Data inline, base64ed | |
| Σ | 0..1 | uri | Uri where the data can be found | |
| Σ | 0..1 | unsignedInt | Number of bytes of content (if url provided) | |
| Σ | 0..1 | base64Binary | Hash of the data (sha-1, base64ed) | |
| Σ | 0..1 | string | Label to display in place of the data | |
| Σ | 0..1 | dateTime | Date attachment was first created | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir"><!-- from Element: extension --> <contentType value="[code]"/><!-- 0..1 Mime type of the content, with charset etc.
JSON Template
{
// from Element: extension
"contentType" : "<code>", // Mime type of the content, with charset etc.
"language" : "<code>", // Human language of the content (BCP-47)
"data" : "<base64Binary>", // Data inline, base64ed
"url" : "<uri>", // Uri where the data can be found
"size" : "<unsignedInt>", // Number of bytes of content (if url provided)
"hash" : "<base64Binary>", // Hash of the data (sha-1, base64ed)
"title" : "<string>", // Label to display in place of the data
"creation" : "<dateTime>" // Date attachment was first created
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Content in a format defined elsewhere It the Attachment has data, it SHALL have a contentType | ||
| Σ | 0..1 | code | Mime type of the content, with charset etc. MimeType | |
| Σ | 0..1 | code | Human language of the content (BCP-47) Language | |
| Σ | 0..1 | base64Binary | Data inline, base64ed | |
| Σ | 0..1 | uri | Uri where the data can be found | |
| Σ | 0..1 | unsignedInt | Number of bytes of content (if url provided) | |
| Σ | 0..1 | base64Binary | Hash of the data (sha-1, base64ed) | |
| Σ | 0..1 | string | Label to display in place of the data | |
| Σ | 0..1 | dateTime | Date attachment was first created | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"contentType" : "<code>", // Mime type of the content, with charset etc.
"language" : "<code>", // Human language of the content (BCP-47)
"data" : "<base64Binary>", // Data inline, base64ed
"url" : "<uri>", // Uri where the data can be found
"size" : "<unsignedInt>", // Number of bytes of content (if url provided)
"hash" : "<base64Binary>", // Hash of the data (sha-1, base64ed)
"title" : "<string>", // Label to display in place of the data
"creation" : "<dateTime>" // Date attachment was first created
}
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.
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
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.
Attachment is used in the following places: BodySite, Communication, CommunicationRequest, Contract, DiagnosticReport, DocumentManifest, DocumentReference, HealthcareService, ImagingStudy, Media, Observation, Patient, Person, Practitioner, QuestionnaireResponse and RelatedPerson
See also Examples, Detailed Descriptions and Mappings.
A Coding is a representation of a defined concept using a symbol from a defined "code system" - see Using Codes in resources for more details.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A reference to a code defined by a terminology system | ||
| Σ | 0..1 | uri | Identity of the terminology system | |
| Σ | 0..1 | string | Version of the system - if relevant | |
| Σ | 0..1 | code | Symbol in syntax defined by the system | |
| Σ | 0..1 | string | Representation defined by the system | |
| Σ | 0..1 | boolean | If this coding was chosen directly by the user | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"system" : "<uri>", // Identity of the terminology system
"version" : "<string>", // Version of the system - if relevant
"code" : "<code>", // Symbol in syntax defined by the system
"display" : "<string>", // Representation defined by the system
"userSelected" : <boolean> // If this coding was chosen directly by the user
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A reference to a code defined by a terminology system | ||
| Σ | 0..1 | uri | Identity of the terminology system | |
| Σ | 0..1 | string | Version of the system - if relevant | |
| Σ | 0..1 | code | Symbol in syntax defined by the system | |
| Σ | 0..1 | string | Representation defined by the system | |
| Σ | 0..1 | boolean | If this coding was chosen directly by the user | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"system" : "<uri>", // Identity of the terminology system
"version" : "<string>", // Version of the system - if relevant
"code" : "<code>", // Symbol in syntax defined by the system
"display" : "<string>", // Representation defined by the system
"userSelected" : <boolean> // If this coding was chosen directly by the user
}
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 adds no other
value.
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 ValueSet with an inline code system, ValueSet.codeSystem.system,
is the correct value for the system uri.
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:
More generally, any classification (e.g. a code system that includes concepts with relative definitions such as "not otherwise coded" will require a version. See the discussion of code system versions in the Value Set resource for further discussion on versioning.
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.
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.
Coding is used in the following places: CodeableConcept, Signature, Account, AuditEvent, Claim, ClaimResponse, Conformance, Contract, Coverage, DocumentReference, EligibilityRequest, EligibilityResponse, EnrollmentRequest, EnrollmentResponse, ExplanationOfBenefit, ImagingStudy, MessageHeader, PaymentNotice, PaymentReconciliation, ProcessRequest, ProcessResponse, Provenance, Questionnaire, QuestionnaireResponse, StructureDefinition, Subscription, TestScript, ValueSet and VisionPrescription
Design Note: This specification defines two types for representing coded values:
- Coding: a simple direct reference to a code defined by a code system
- CodeableConcept: a text description and/or a list of Codings (i.e. a list of references to codes defined by code systems)
The
Codingdata 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
Codingdata 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.
See also Examples, Detailed Descriptions and Mappings.
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.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | Concept - reference to a terminology or just text | ||
| Σ | 0..* | Coding | Code defined by a terminology system | |
| Σ | 0..1 | string | Plain text representation of the concept | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"coding" : [{ Coding }], // Code defined by a terminology system
"text" : "<string>" // Plain text representation of the concept
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | Concept - reference to a terminology or just text | ||
| Σ | 0..* | Coding | Code defined by a terminology system | |
| Σ | 0..1 | string | Plain text representation of the concept | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"coding" : [{ Coding }], // Code defined by a terminology system
"text" : "<string>" // Plain text representation of the concept
}
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.
CodeableConcept is used in the following places: Identifier, Account, AllergyIntolerance, Appointment, AppointmentResponse, AuditEvent, Basic, BodySite, CarePlan, ClinicalImpression, Communication, CommunicationRequest, Composition, ConceptMap, Condition, Conformance, Contract, DataElement, DetectedIssue, Device, DeviceComponent, DeviceMetric, DeviceUseRequest, DeviceUseStatement, DiagnosticOrder, DiagnosticReport, DocumentManifest, DocumentReference, Encounter, EpisodeOfCare, FamilyMemberHistory, Flag, Goal, Group, HealthcareService, ImagingObjectSelection, Immunization, ImmunizationRecommendation, ImplementationGuide, List, Location, Media, Medication, MedicationAdministration, MedicationDispense, MedicationOrder, MedicationStatement, MessageHeader, NamingSystem, NutritionOrder, Observation, OperationOutcome, Order, Organization, Patient, Practitioner, Procedure, ProcedureRequest, Provenance, ReferralRequest, RelatedPerson, RiskAssessment, Schedule, Slot, Specimen, StructureDefinition, Substance, SupplyDelivery, SupplyRequest, TestScript, ValueSet and VisionPrescription
See also Examples, Detailed Descriptions and Mappings.
A measured amount (or an amount that can potentially be measured).
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | A measured or measurable amount If a code for the unit is present, the system SHALL also be present | ||
| Σ | 0..1 | decimal | Numerical value (with implicit precision) | |
| ?! Σ | 0..1 | code | < | <= | >= | > - how to understand the value QuantityComparator (Required) | |
| Σ | 0..1 | string | Unit representation | |
| Σ I | 0..1 | uri | System that defines coded unit form | |
| Σ | 0..1 | code | Coded form of the unit | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">0..1 System that defines coded unit form --> <code value="[code]"/><!-- 0..1 Coded form of the unit --> </[name]>
JSON Template
{
// from Element: extension
"value" : <decimal>, // Numerical value (with implicit precision)
"comparator" : "<code>", // < | <= | >= | > - how to understand the value
"unit" : "<string>", // Unit representation
"system" : "<uri>", // C? System that defines coded unit form
"code" : "<code>" // Coded form of the unit
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | A measured or measurable amount If a code for the unit is present, the system SHALL also be present | ||
| Σ | 0..1 | decimal | Numerical value (with implicit precision) | |
| ?! Σ | 0..1 | code | < | <= | >= | > - how to understand the value QuantityComparator (Required) | |
| Σ | 0..1 | string | Unit representation | |
| Σ I | 0..1 | uri | System that defines coded unit form | |
| Σ | 0..1 | code | Coded form of the unit | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"value" : <decimal>, // Numerical value (with implicit precision)
"comparator" : "<code>", // < | <= | >= | > - how to understand the value
"unit" : "<string>", // Unit representation
"system" : "<uri>", // C? System that defines coded unit form
"code" : "<code>" // Coded form of the unit
}
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 is able to 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 actually a valid UCUM unit, but it cannot be assumed that the unit actually contains a valid UCUM unit.
Constraints
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.
Quantity is used in the following places: Ratio, Group, Observation and QuestionnaireResponse
These are used as types in resource content models, but they are really just a Quantity with some rules:
| Age | A duration (length of time) with a UCUM code | StructureDefinition (XML, JSON) | Condition and FamilyMemberHistory |
| Count | A count of a discrete element (no unit) | StructureDefinition (XML, JSON) | (not used as yet) |
| Money | An amount of money. With regard to precision, see [Decimal Precision](datatypes.html#precision) | StructureDefinition (XML, JSON) | Account, Claim, ClaimResponse, Contract and PaymentReconciliation |
| Distance | A measure of distance | StructureDefinition (XML, JSON) | (not used as yet) |
| Duration | A length of time | StructureDefinition (XML, JSON) | Encounter, Goal and MedicationOrder |
| SimpleQuantity | A fixed quantity (no comparator) | StructureDefinition (XML, JSON) | Range, SampledData, CarePlan, Claim, Contract, Immunization, Medication, MedicationAdministration, MedicationDispense, MedicationOrder, MedicationStatement, NutritionOrder, Observation, Specimen, Substance, SupplyDelivery and VisionPrescription |
See also Examples, Detailed Descriptions and Mappings.
A set of ordered Quantity values defined by a low and high limit.
A Range specifies a set of possible values; usually, one value from the range applies (e.g. "give the patient between 2 and 4 tablets"). Ranges are typically used in instructions.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Set of values bounded by low and high If present, low SHALL have a lower value than high | ||
| Σ I | 0..1 | SimpleQuantity | Low limit | |
| Σ I | 0..1 | SimpleQuantity | High limit | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"low" : { Quantity(SimpleQuantity) }, // C? Low limit
"high" : { Quantity(SimpleQuantity) } // C? High limit
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Set of values bounded by low and high If present, low SHALL have a lower value than high | ||
| Σ I | 0..1 | SimpleQuantity | Low limit | |
| Σ I | 0..1 | SimpleQuantity | High limit | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"low" : { Quantity(SimpleQuantity) }, // C? Low limit
"high" : { Quantity(SimpleQuantity) } // C? High limit
}
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
Range is used in the following places: Condition, FamilyMemberHistory, Group, MedicationAdministration, MedicationDispense, MedicationOrder, MedicationStatement, Observation and RiskAssessment
See also Examples, Detailed Descriptions and Mappings.
A relationship between two Quantity values expressed as a numerator and a denominator.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | 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 present | ||
| Σ | 0..1 | Quantity | Numerator value | |
| Σ | 0..1 | Quantity | Denominator value | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"numerator" : { Quantity }, // Numerator value
"denominator" : { Quantity } // Denominator value
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | 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 present | ||
| Σ | 0..1 | Quantity | Numerator value | |
| Σ | 0..1 | Quantity | Denominator value | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"numerator" : { Quantity }, // Numerator value
"denominator" : { Quantity } // Denominator value
}
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
The context of use may require particular types of Quantity for the numerator or denominator.
Ratio is used in the following places: Medication, MedicationAdministration, MedicationDispense, MedicationOrder, MedicationStatement, NutritionOrder, Observation and Substance
See also Examples, Detailed Descriptions and Mappings.
A time period defined by a start and end date/time.
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").
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Time range defined by start and end date/time If present, start SHALL have a lower value than end | ||
| Σ I | 0..1 | dateTime | Starting time with inclusive boundary | |
| Σ I | 0..1 | dateTime | End time with inclusive boundary, if not ongoing | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"start" : "<dateTime>", // C? Starting time with inclusive boundary
"end" : "<dateTime>" // C? End time with inclusive boundary, if not ongoing
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Time range defined by start and end date/time If present, start SHALL have a lower value than end | ||
| Σ I | 0..1 | dateTime | Starting time with inclusive boundary | |
| Σ I | 0..1 | dateTime | End time with inclusive boundary, if not ongoing | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"start" : "<dateTime>", // C? Starting time with inclusive boundary
"end" : "<dateTime>" // C? End time with inclusive boundary, if not ongoing
}
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.
Period is used in the following places: Identifier, Account, CarePlan, CommunicationRequest, Composition, Condition, Contract, Coverage, DeviceUseRequest, DeviceUseStatement, DiagnosticReport, DocumentReference, Encounter, EpisodeOfCare, FamilyMemberHistory, Flag, Group, HealthcareService, MedicationAdministration, MedicationOrder, MedicationStatement, NamingSystem, Observation, Patient, PaymentReconciliation, Practitioner, Procedure, ProcedureRequest, ProcessRequest, Provenance, ReferralRequest, RelatedPerson, RiskAssessment, Schedule, Specimen and SupplyDelivery
See also Examples, Detailed Descriptions and Mappings.
Data that comes from a series of measurements taken by a device, with upper and lower limits. There may be more than one dimension in the data.
A SampledData provides a concise way to handle the data produced by devices that sample a physical particular state at a high frequency. A typical use for this is for the output of an ECG or EKG device.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A series of measurements taken by a device | ||
| Σ | 1..1 | SimpleQuantity | Zero value and units | |
| Σ | 1..1 | decimal | Number of milliseconds between samples | |
| Σ | 0..1 | decimal | Multiply data by this before adding to origin | |
| Σ | 0..1 | decimal | Lower limit of detection | |
| Σ | 0..1 | decimal | Upper limit of detection | |
| Σ | 1..1 | positiveInt | Number of sample points at each time point | |
| Σ | 1..1 | string | Decimal values with spaces, or "E" | "U" | "L" | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"origin" : { Quantity(SimpleQuantity) }, // R! Zero value and units
"period" : <decimal>, // R! Number of milliseconds between samples
"factor" : <decimal>, // Multiply data by this before adding to origin
"lowerLimit" : <decimal>, // Lower limit of detection
"upperLimit" : <decimal>, // Upper limit of detection
"dimensions" : "<positiveInt>", // R! Number of sample points at each time point
"data" : "<string>" // R! Decimal values with spaces, or "E" | "U" | "L"
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A series of measurements taken by a device | ||
| Σ | 1..1 | SimpleQuantity | Zero value and units | |
| Σ | 1..1 | decimal | Number of milliseconds between samples | |
| Σ | 0..1 | decimal | Multiply data by this before adding to origin | |
| Σ | 0..1 | decimal | Lower limit of detection | |
| Σ | 0..1 | decimal | Upper limit of detection | |
| Σ | 1..1 | positiveInt | Number of sample points at each time point | |
| Σ | 1..1 | string | Decimal values with spaces, or "E" | "U" | "L" | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"origin" : { Quantity(SimpleQuantity) }, // R! Zero value and units
"period" : <decimal>, // R! Number of milliseconds between samples
"factor" : <decimal>, // Multiply data by this before adding to origin
"lowerLimit" : <decimal>, // Lower limit of detection
"upperLimit" : <decimal>, // Upper limit of detection
"dimensions" : "<positiveInt>", // R! Number of sample points at each time point
"data" : "<string>" // R! Decimal values with spaces, or "E" | "U" | "L"
}
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.
SampledData is used in the following places: Observation
See also Examples, Detailed Descriptions and Mappings.
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.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | An identifier intended for computation | ||
| ?! Σ | 0..1 | code | usual | official | temp | secondary (If known) IdentifierUse (Required) | |
| Σ | 0..1 | CodeableConcept | Description of identifier Identifier Type Codes (Extensible) | |
| Σ | 0..1 | uri | The namespace for the identifier | |
| Σ | 0..1 | string | The value that is unique | |
| Σ | 0..1 | Period | Time period when id is/was valid for use | |
| Σ | 0..1 | Reference(Organization) | Organization that issued id (may be just text) | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"use" : "<code>", // usual | official | temp | secondary (If known)
"type" : { CodeableConcept }, // Description of identifier
"system" : "<uri>", // The namespace for the identifier
"value" : "<string>", // The value that is unique
"period" : { Period }, // Time period when id is/was valid for use
"assigner" : { Reference(Organization) } // Organization that issued id (may be just text)
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | An identifier intended for computation | ||
| ?! Σ | 0..1 | code | usual | official | temp | secondary (If known) IdentifierUse (Required) | |
| Σ | 0..1 | CodeableConcept | Description of identifier Identifier Type Codes (Extensible) | |
| Σ | 0..1 | uri | The namespace for the identifier | |
| Σ | 0..1 | string | The value that is unique | |
| Σ | 0..1 | Period | Time period when id is/was valid for use | |
| Σ | 0..1 | Reference(Organization) | Organization that issued id (may be just text) | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"use" : "<code>", // usual | official | temp | secondary (If known)
"type" : { CodeableConcept }, // Description of identifier
"system" : "<uri>", // The namespace for the identifier
"value" : "<string>", // The value that is unique
"period" : { Period }, // Time period when id is/was valid for use
"assigner" : { Reference(Organization) } // Organization that issued id (may be just text)
}
The system referred to by means of a URI defines how the identifier is defined (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. 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.
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.
FHIR defines some useful URIs directly. OIDs (urn:oid:) and UUIDs (urn:uuid:)
may be registered in the HL7 OID registry and should be if the
content is shared or exchanged across institutional boundaries. If the identifier itself
is naturally globally unique (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.
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. This practice should be avoided where possible, as information sharing in a wider context is very likely to arise eventually, and values without a system are inherently limited in use.
The assigner is used to indicate what registry/state/facility/etc. assigned the identifier.
Identifier is used in the following places: Account, AllergyIntolerance, Appointment, AppointmentResponse, AuditEvent, Basic, BodySite, CarePlan, Claim, ClaimResponse, Communication, CommunicationRequest, Composition, ConceptMap, Condition, Contract, Coverage, DataElement, DetectedIssue, Device, DeviceComponent, DeviceMetric, DeviceUseRequest, DeviceUseStatement, DiagnosticOrder, DiagnosticReport, DocumentManifest, DocumentReference, EligibilityRequest, EligibilityResponse, Encounter, EnrollmentRequest, EnrollmentResponse, EpisodeOfCare, ExplanationOfBenefit, FamilyMemberHistory, Flag, Goal, Group, HealthcareService, ImagingStudy, Immunization, ImmunizationRecommendation, List, Location, Media, MedicationAdministration, MedicationDispense, MedicationOrder, MedicationStatement, NutritionOrder, Observation, Order, OrderResponse, Organization, Patient, PaymentNotice, PaymentReconciliation, Person, Practitioner, Procedure, ProcedureRequest, ProcessRequest, ProcessResponse, Provenance, Questionnaire, QuestionnaireResponse, ReferralRequest, RelatedPerson, RiskAssessment, Schedule, Slot, Specimen, StructureDefinition, Substance, SupplyDelivery, SupplyRequest, TestScript, ValueSet and VisionPrescription
See also Examples, Detailed Descriptions and Mappings.
A name of a human with text, parts and usage information.
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.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | Name of a human - parts and usage | ||
| ?! Σ | 0..1 | code | usual | official | temp | nickname | anonymous | old | maiden NameUse (Required) | |
| Σ | 0..1 | string | Text representation of the full name | |
| Σ | 0..* | string | Family name (often called 'Surname') | |
| Σ | 0..* | string | Given names (not always 'first'). Includes middle names | |
| Σ | 0..* | string | Parts that come before the name | |
| Σ | 0..* | string | Parts that come after the name | |
| Σ | 0..1 | Period | Time period when name was/is in use | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "HumanName",
// from Element: extension
"use" : "<code>", // usual | official | temp | nickname | anonymous | old | maiden
"text" : "<string>", // Text representation of the full name
"family" : ["<string>"], // Family name (often called 'Surname')
"given" : ["<string>"], // Given names (not always 'first'). Includes middle names
"prefix" : ["<string>"], // Parts that come before the name
"suffix" : ["<string>"], // Parts that come after the name
"period" : { Period } // Time period when name was/is in use
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | Name of a human - parts and usage | ||
| ?! Σ | 0..1 | code | usual | official | temp | nickname | anonymous | old | maiden NameUse (Required) | |
| Σ | 0..1 | string | Text representation of the full name | |
| Σ | 0..* | string | Family name (often called 'Surname') | |
| Σ | 0..* | string | Given names (not always 'first'). Includes middle names | |
| Σ | 0..* | string | Parts that come before the name | |
| Σ | 0..* | string | Parts that come after the name | |
| Σ | 0..1 | Period | Time period when name was/is in use | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "HumanName",
// from Element: extension
"use" : "<code>", // usual | official | temp | nickname | anonymous | old | maiden
"text" : "<string>", // Text representation of the full name
"family" : ["<string>"], // Family name (often called 'Surname')
"given" : ["<string>"], // Given names (not always 'first'). Includes middle names
"prefix" : ["<string>"], // Parts that come before the name
"suffix" : ["<string>"], // Parts that come after the name
"period" : { Period } // Time period when name was/is in use
}
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 repeats |
| Initials | Q. | Given Name as initial ("." recommended) |
| Nick Name | Jock | Given name, with Use = common |
| Qualifications | PhD | Suffix |
| Honorifics | Senior | Suffix |
For further information, including all W3C International Examples ,
consult the examples.
The multiple given and family name parts combine to form a single name. Multiple given and family names are for
when a person's name has multiple given names (relatively common across cultures) and multiple surnames (less common).
Where a person has alternate names that may be used in place of each other, 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 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.
The parts of a name SHOULD NOT contain whitespace. For family name, hyphenated names such as "Smith-Jones" are a single name, but names with spaces such as "Smith Jones" are broken into multiple parts. For given names, 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.
Applications updating a name SHALL ensure either that the text and the parts are in agreement, or that only one of the two is present. Systems that do not support as many name parts as are provided in an instance may wish to append some of the parts together using spaces
HumanName is used in the following places: Organization, Patient, Person, Practitioner and RelatedPerson
See also Examples, Detailed Descriptions and Mappings.
A postal address. There are a variety of postal address formats defined around the world. Postal addresses are often also used to record a location that can be visited to find a patient or person.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A postal address | ||
| ?! Σ | 0..1 | code | home | work | temp | old - purpose of this address AddressUse (Required) | |
| Σ | 0..1 | code | postal | physical | both AddressType (Required) | |
| Σ | 0..1 | string | Text representation of the address | |
| Σ | 0..* | string | Street name, number, direction & P.O. Box etc. | |
| Σ | 0..1 | string | Name of city, town etc. | |
| Σ | 0..1 | string | District name (aka county) | |
| Σ | 0..1 | string | Sub-unit of country (abbreviations ok) | |
| Σ | 0..1 | string | Postal code for area | |
| Σ | 0..1 | string | Country (can be ISO 3166 3 letter code) | |
| Σ | 0..1 | Period | Time period when address was/is in use | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "Address",
// from Element: extension
"use" : "<code>", // home | work | temp | old - purpose of this address
"type" : "<code>", // postal | physical | both
"text" : "<string>", // Text representation of the address
"line" : ["<string>"], // Street name, number, direction & P.O. Box etc.
"city" : "<string>", // Name of city, town etc.
"district" : "<string>", // District name (aka county)
"state" : "<string>", // Sub-unit of country (abbreviations ok)
"postalCode" : "<string>", // Postal code for area
"country" : "<string>", // Country (can be ISO 3166 3 letter code)
"period" : { Period } // Time period when address was/is in use
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A postal address | ||
| ?! Σ | 0..1 | code | home | work | temp | old - purpose of this address AddressUse (Required) | |
| Σ | 0..1 | code | postal | physical | both AddressType (Required) | |
| Σ | 0..1 | string | Text representation of the address | |
| Σ | 0..* | string | Street name, number, direction & P.O. Box etc. | |
| Σ | 0..1 | string | Name of city, town etc. | |
| Σ | 0..1 | string | District name (aka county) | |
| Σ | 0..1 | string | Sub-unit of country (abbreviations ok) | |
| Σ | 0..1 | string | Postal code for area | |
| Σ | 0..1 | string | Country (can be ISO 3166 3 letter code) | |
| Σ | 0..1 | Period | Time period when address was/is in use | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "Address",
// from Element: extension
"use" : "<code>", // home | work | temp | old - purpose of this address
"type" : "<code>", // postal | physical | both
"text" : "<string>", // Text representation of the address
"line" : ["<string>"], // Street name, number, direction & P.O. Box etc.
"city" : "<string>", // Name of city, town etc.
"district" : "<string>", // District name (aka county)
"state" : "<string>", // Sub-unit of country (abbreviations ok)
"postalCode" : "<string>", // Postal code for area
"country" : "<string>", // Country (can be ISO 3166 3 letter code)
"period" : { Period } // Time period when address was/is in use
}
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.
Constraints
Address is used in the following places: Location, Organization, Patient, Person, Practitioner and RelatedPerson
See also Examples, Detailed Descriptions and Mappings.
Details for all kinds of technology-mediated contact points for a person or organization, including telephone, email, etc.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Details of a Technology mediated contact point (phone, fax, email, etc.) A system is required if a value is provided. | ||
| Σ I | 0..1 | code | phone | fax | email | pager | other ContactPointSystem (Required) | |
| Σ | 0..1 | string | The actual contact point details | |
| ?! Σ | 0..1 | code | home | work | temp | old | mobile - purpose of this contact point ContactPointUse (Required) | |
| Σ | 0..1 | positiveInt | Specify preferred order of use (1 = highest) | |
| Σ | 0..1 | Period | Time period when the contact point was/is in use | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "ContactPoint",
// from Element: extension
"system" : "<code>", // C? phone | fax | email | pager | other
"value" : "<string>", // The actual contact point details
"use" : "<code>", // home | work | temp | old | mobile - purpose of this contact point
"rank" : "<positiveInt>", // Specify preferred order of use (1 = highest)
"period" : { Period } // Time period when the contact point was/is in use
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ I | Element | Details of a Technology mediated contact point (phone, fax, email, etc.) A system is required if a value is provided. | ||
| Σ I | 0..1 | code | phone | fax | email | pager | other ContactPointSystem (Required) | |
| Σ | 0..1 | string | The actual contact point details | |
| ?! Σ | 0..1 | code | home | work | temp | old | mobile - purpose of this contact point ContactPointUse (Required) | |
| Σ | 0..1 | positiveInt | Specify preferred order of use (1 = highest) | |
| Σ | 0..1 | Period | Time period when the contact point was/is in use | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "ContactPoint",
// from Element: extension
"system" : "<code>", // C? phone | fax | email | pager | other
"value" : "<string>", // The actual contact point details
"use" : "<code>", // home | work | temp | old | mobile - purpose of this contact point
"rank" : "<positiveInt>", // Specify preferred order of use (1 = highest)
"period" : { Period } // Time period when the contact point was/is in use
}
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, page and email addresses are not handled as formal URLs. For other kinds
of contacts, 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
ContactPoint is used in the following places: ConceptMap, Conformance, DataElement, Device, HealthcareService, ImplementationGuide, Location, MessageHeader, NamingSystem, OperationDefinition, Organization, Patient, Person, Practitioner, Questionnaire, RelatedPerson, SearchParameter, StructureDefinition, Subscription, TestScript and ValueSet
See also Examples, Detailed Descriptions and Mappings.
Specifies an event that may occur multiple times. Timing schedules are not used for recording when things did happen, but when they are expected or requested to occur. A Timing schedule can be a list of events and/or criteria for when the event is to happen, 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.
Many systems avoid the complexity of the Timing structure by using a text field for these things (e.g. "Dosage Text"). Those systems do not use the Timing data type. Other systems use a set of 'common' codes - including, but usually not limited to, widely understood acronyms such as "BID". A structured timing specification SHOULD be provided whenever possible, unless the code is BID, TID, QID, AM or PM, which have a ubiquitous meaning.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A timing schedule that specifies an event that may occur multiple times | ||
| Σ | 0..* | dateTime | When the event occurs | |
| Σ I | 0..1 | Element | When the event is to occur Either frequency or when can exist, not both if there's a duration, there needs to be duration units if there's a period, there needs to be period units If there's a periodMax, there must be a period If there's a durationMax, there must be a duration | |
| Σ | 0..1 | Length/Range of lengths, or (Start and/or end) limits | ||
| Duration | ||||
| Range | ||||
| Period | ||||
| Σ | 0..1 | integer | Number of times to repeat | |
| Σ I | 0..1 | decimal | How long when it happens duration SHALL be a non-negative value | |
| Σ | 0..1 | decimal | How long when it happens (Max) | |
| Σ | 0..1 | code | s | min | h | d | wk | mo | a - unit of time (UCUM) UnitsOfTime (Required) | |
| Σ | 0..1 | integer | Event occurs frequency times per period | |
| Σ | 0..1 | integer | Event occurs up to frequencyMax times per period | |
| Σ I | 0..1 | decimal | Event occurs frequency times per period period SHALL be a non-negative value | |
| Σ | 0..1 | decimal | Upper limit of period (3-4 hours) | |
| Σ | 0..1 | code | s | min | h | d | wk | mo | a - unit of time (UCUM) UnitsOfTime (Required) | |
| Σ | 0..1 | code | Regular life events the event is tied to EventTiming (Required) | |
| Σ | 0..1 | CodeableConcept | QD | QOD | Q4H | Q6H | BID | TID | QID | AM | PM + TimingAbbreviation (Preferred) | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "Timing",
// from Element: extension
"event" : ["<dateTime>"], // When the event occurs
"repeat" : { // When the event is to occur
// bounds[x]: Length/Range of lengths, or (Start and/or end) limits. One of these 3:
"boundsQuantity" : { Quantity(Duration) },
"boundsRange" : { Range },
"boundsPeriod" : { Period },
"count" : <integer>, // Number of times to repeat
"duration" : <decimal>, // How long when it happens
"durationMax" : <decimal>, // How long when it happens (Max)
"durationUnits" : "<code>", // s | min | h | d | wk | mo | a - unit of time (UCUM)
"frequency" : <integer>, // Event occurs frequency times per period
"frequencyMax" : <integer>, // Event occurs up to frequencyMax times per period
"period" : <decimal>, // Event occurs frequency times per period
"periodMax" : <decimal>, // Upper limit of period (3-4 hours)
"periodUnits" : "<code>", // s | min | h | d | wk | mo | a - unit of time (UCUM)
"when" : "<code>" // Regular life events the event is tied to
},
"code" : { CodeableConcept } // QD | QOD | Q4H | Q6H | BID | TID | QID | AM | PM +
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A timing schedule that specifies an event that may occur multiple times | ||
| Σ | 0..* | dateTime | When the event occurs | |
| Σ I | 0..1 | Element | When the event is to occur Either frequency or when can exist, not both if there's a duration, there needs to be duration units if there's a period, there needs to be period units If there's a periodMax, there must be a period If there's a durationMax, there must be a duration | |
| Σ | 0..1 | Length/Range of lengths, or (Start and/or end) limits | ||
| Duration | ||||
| Range | ||||
| Period | ||||
| Σ | 0..1 | integer | Number of times to repeat | |
| Σ I | 0..1 | decimal | How long when it happens duration SHALL be a non-negative value | |
| Σ | 0..1 | decimal | How long when it happens (Max) | |
| Σ | 0..1 | code | s | min | h | d | wk | mo | a - unit of time (UCUM) UnitsOfTime (Required) | |
| Σ | 0..1 | integer | Event occurs frequency times per period | |
| Σ | 0..1 | integer | Event occurs up to frequencyMax times per period | |
| Σ I | 0..1 | decimal | Event occurs frequency times per period period SHALL be a non-negative value | |
| Σ | 0..1 | decimal | Upper limit of period (3-4 hours) | |
| Σ | 0..1 | code | s | min | h | d | wk | mo | a - unit of time (UCUM) UnitsOfTime (Required) | |
| Σ | 0..1 | code | Regular life events the event is tied to EventTiming (Required) | |
| Σ | 0..1 | CodeableConcept | QD | QOD | Q4H | Q6H | BID | TID | QID | AM | PM + TimingAbbreviation (Preferred) | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "Timing",
// from Element: extension
"event" : ["<dateTime>"], // When the event occurs
"repeat" : { // When the event is to occur
// bounds[x]: Length/Range of lengths, or (Start and/or end) limits. One of these 3:
"boundsQuantity" : { Quantity(Duration) },
"boundsRange" : { Range },
"boundsPeriod" : { Period },
"count" : <integer>, // Number of times to repeat
"duration" : <decimal>, // How long when it happens
"durationMax" : <decimal>, // How long when it happens (Max)
"durationUnits" : "<code>", // s | min | h | d | wk | mo | a - unit of time (UCUM)
"frequency" : <integer>, // Event occurs frequency times per period
"frequencyMax" : <integer>, // Event occurs up to frequencyMax times per period
"period" : <decimal>, // Event occurs frequency times per period
"periodMax" : <decimal>, // Upper limit of period (3-4 hours)
"periodUnits" : "<code>", // s | min | h | d | wk | mo | a - unit of time (UCUM)
"when" : "<code>" // Regular life events the event is tied to
},
"code" : { CodeableConcept } // QD | QOD | Q4H | Q6H | BID | TID | QID | AM | PM +
}
If the timing schedule has repeating criteria, the repeat can occur a given number of times per the specified duration or in relation to some real world event. If no end condition is specified, the schedule will terminate on some criteria that are expressed elsewhere.
If duration is provided as a Range, the unit in the Range
SHALL be a UCUM unit of time.
This table summarises some common uses of the Timing Data Type criteria.
| description | duration | durationUnits | frequency | frequencyMax | period | periodUnits | periodMax | when | bounds[x] |
| BID | 2 | 1 | d | ||||||
| TID | 3 | 1 | d | ||||||
| QID | 4 | 1 | d | ||||||
| Q6H | 1 | 6 | h | ||||||
| Every 8 hours | 1 | 8 | h | ||||||
| Every 7 days | 1 | 7 | d | ||||||
| 3 times a day | 3 | 1 | d | ||||||
| 3-4 times a day | 3 | 4 | 1 | d | |||||
| Every 4-6 hours | 1 | 4 | h | 6 | |||||
| Every 21 days for 1 hour | 1 | hr | 1 | 21 | d | ||||
| Three times a week for ½ hour | 0.5 | hr | 3 | 1 | wk | ||||
| With breakfast | CM | ||||||||
| For 5 minutes, 10 minutes before meals | 5 | min | 10 | min | AC | ||||
| TID, for 14 days | 3 | 1 | d | Duration = 14 days | |||||
| BID, start on 7/1/2015 at 1:00 PM | 2 | 1 | d | Period, low = 2015-07-01T13:00:00 | |||||
Constraints
Timing is used in the following places: CarePlan, DeviceMetric, DeviceUseRequest, DeviceUseStatement, MedicationDispense, MedicationOrder, MedicationStatement, NutritionOrder, Order, ProcedureRequest and SupplyRequest
See also Examples, Detailed Descriptions and Mappings.
A Signature holds an electronic representation of a signature and its supporting context in a FHIR accessible form. The signature may either be a cryptographic type (XML DigSig or a JWT), which is able to provide non-repudiation proof, or it may be a graphical image that represents a signature or a signature process.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A digital Signature - XML DigSig, JWT, Graphical image of signature, etc. | ||
| Σ | 1..* | Coding | Indication of the reason the entity signed the object(s) Signature Type Codes (Preferred) | |
| Σ | 1..1 | instant | When the signature was created | |
| Σ | 1..1 | Who signed the signature | ||
| uri | ||||
| Reference(Practitioner | RelatedPerson | Patient | Device | Organization) | ||||
| Σ | 1..1 | code | The technical format of the signature MimeType | |
| Σ | 1..1 | base64Binary | The actual signature content (XML DigSig. JWT, picture, etc.) | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"type" : [{ Coding }], // R! Indication of the reason the entity signed the object(s)
"when" : "<instant>", // R! When the signature was created
// who[x]: Who signed the signature. One of these 2:
"whoUri" : "<uri>",
"whoReference" : { Reference(Practitioner|RelatedPerson|Patient|Device|
Organization) },
"contentType" : "<code>", // R! The technical format of the signature
"blob" : "<base64Binary>" // R! The actual signature content (XML DigSig. JWT, picture, etc.)
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | A digital Signature - XML DigSig, JWT, Graphical image of signature, etc. | ||
| Σ | 1..* | Coding | Indication of the reason the entity signed the object(s) Signature Type Codes (Preferred) | |
| Σ | 1..1 | instant | When the signature was created | |
| Σ | 1..1 | Who signed the signature | ||
| uri | ||||
| Reference(Practitioner | RelatedPerson | Patient | Device | Organization) | ||||
| Σ | 1..1 | code | The technical format of the signature MimeType | |
| Σ | 1..1 | base64Binary | The actual signature content (XML DigSig. JWT, picture, etc.) | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
"type" : [{ Coding }], // R! Indication of the reason the entity signed the object(s)
"when" : "<instant>", // R! When the signature was created
// who[x]: Who signed the signature. One of these 2:
"whoUri" : "<uri>",
"whoReference" : { Reference(Practitioner|RelatedPerson|Patient|Device|
Organization) },
"contentType" : "<code>", // R! The technical format of the signature
"blob" : "<base64Binary>" // R! The actual signature content (XML DigSig. JWT, picture, etc.)
}
Constraints
Note: One consequence of signing the document is that URLs, identifiers and internal references are frozen and cannot be changed. This might be a desired feature, but it may also cripple interoperability between closed ecosystems where re-identification frequently occurs. For this reason, it is recommended that systems consider carefully the impact of any signature processes. The impact of signatures on Document bundles and their related processes is the most well understood use of digital signatures.
When the signature is an XML Digital Signature (contentType = application/signature+xml), the following rules apply:
There are three levels of signature verification:
Deviations from these guidelines would need to be expressed in site policy, and would be enumerated in the XML-Signature block. For example some environments may choose a different XAdES profile, hashing algorithm, policy identifier, or signature purpose vocabulary.
Signature is used in the following places: Bundle and Provenance
See also Examples, Detailed Descriptions and Mappings.
A text note which also contains information about who made the statement and when.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | Text node with attribution | ||
| Σ | 0..1 | Individual responsible for the annotation | ||
| Reference(Practitioner | Patient | RelatedPerson) | ||||
| string | ||||
| Σ | 0..1 | dateTime | When the annotation was made | |
| Σ | 1..1 | string | The annotation - text content | |
UML Diagram
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
// author[x]: Individual responsible for the annotation. One of these 2:
"authorReference" : { Reference(Practitioner|Patient|RelatedPerson) },
"authorString" : "<string>",
"time" : "<dateTime>", // When the annotation was made
"text" : "<string>" // R! The annotation - text content
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| Σ | Element | Text node with attribution | ||
| Σ | 0..1 | Individual responsible for the annotation | ||
| Reference(Practitioner | Patient | RelatedPerson) | ||||
| string | ||||
| Σ | 0..1 | dateTime | When the annotation was made | |
| Σ | 1..1 | string | The annotation - text content | |
XML Template
<[name] xmlns="http://hl7.org/fhir">
JSON Template
{
// from Element: extension
// author[x]: Individual responsible for the annotation. One of these 2:
"authorReference" : { Reference(Practitioner|Patient|RelatedPerson) },
"authorString" : "<string>",
"time" : "<dateTime>", // When the annotation was made
"text" : "<string>" // R! The annotation - text content
}
Systems that do not have structured annotations simply communicate a single annotation with no author or time.
This element may need to be included in narrative because of the potential for modifying information.
Annotations SHOULD NOT be used to communicate "modifying" information that could be computable (this is a SHOULD because enforcing user behavior is nearly impossible).
Annotation is used in the following places: AllergyIntolerance, CarePlan, Device, DiagnosticOrder, FamilyMemberHistory, Goal, Immunization, Procedure and ProcedureRequest
Some elements do not have a specified type. The type is represented by the wildcard symbol "*". In these cases, the element type may be one of the following:
The element name ends with "[x]", and this is replaced with the Title cased name of the data type.
Open references are used in the following places: Parameters
The following types are defined as part of the data types, but are documented elsewhere in the specification:
© HL7.org 2011+. FHIR DSTU2 (v1.0.2-7202) generated on Sat, Oct 24, 2015 07:44+1100.
Links: Search |
Version History |
Table of Contents |
Compare to DSTU1
|
|
Propose a change