Guidance

DataType Guidance

This page gives guidance on the representation of constructs like:

  • Representing contact methods such as telephones using ContactPoint
  • Representing structured addresses using Address
  • Representing structured names using HumanName

ContactPoint

Details for all kinds of technology-mediated contact points for a person or organisation, including telephone, email, etc.

The ContactPoint datatype has the following elements and this is an overview of the datatype with additional UK Core guidance. The full definition is available from the FHIR standard.

Element type Usage Guidance Description
system code SHALL be present Details for all kinds of technology-mediated contact points for a person or organisation, including telephone, email, etc.
value string SHALL be present The actual contact point details
use code MAY be present Identifies the purpose for the contact point.
rank positiveInt MAY be present Specifies a preferred order in which to use a set of contacts. ContactPoints with lower rank values are more preferred than those with higher rank values.
period Period MAY be present Time period when the contact point was/is in use.

Address

An address expressed using postal conventions (as opposed to GPS or other location definition formats). This datatype 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 Address datatype has the following elements and this is an overview of the datatype with additional UK Core guidance. The full definition is available from the FHIR standard.

Element type Usage Guidance Description
use code SHOULD be present The purpose of this address
type code SHOULD be present The type of address
text string MAY be present Text representation of the address
line string SHOULD be present Street name, number, direction & P.O. Box etc.This repeating element order: The order in which lines SHOULD appear in an address label
city string SHOULD be present Name of city, town etc
district string MAY be present District name (aka county)
state string MAY be present Sub-unit of country (abbreviations ok)
postalCode string SHOULD be present postalCode - Code for area
country string MAY be present Country (e.g. can be ISO 3166 2 or 3 letter code)
period Period MAY be present Time period when the address was/is in use

Unstructured Addresses

text

Text representation of the address. This SHOULD only be used if a structured address as detailed below cannot be supported. It MAY be present in addition to a structured address.

Structured Addresses

Structured addresses SHOULD be used whenever possible as detailed below.

line

Street name, number, direction & P.O. Box etc. This repeating element order: The order in which lines SHOULD appear in an address label. Parts of the address that have distinct elements listed below SHOULD not appear in the address line elements.

The following elements SHOULD be used to carry the associated information.

  • city - Name of city, town etc
  • district - District name (aka county)
  • state - Sub-unit of country (abbreviations ok)
  • postalCode - Postal code for area
  • country - Country (e.g. can be ISO 3166 2 or 3 letter code)

HumanName

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 types that have variable significance depending on context, though the division into parts is not always significant. With personal names, the different parts might or might not be imbued with some implicit meaning; various cultures associate different importance with the name parts and the degree to which systems do care about name parts around the world varies widely.

The HumanName datatype has the following elements and this is an overview of the datatype with additional UK Core guidance. The full definition is available from the FHIR standard.

Element Type Usage Guidance Description
use code SHOULD be present Identifies the purpose for this name. Allows the appropriate name for a particular context of use to be selected from among a set of names. Applications can assume that a name is current unless it explicitly says that it is temporary or old.
text string MAY be present Text representation of the full name. Specifies the entire name as it SHOULD be displayed e.g. on an application UI. This MAY be provided instead of or as well as the specific parts. Applications updating a name SHALL ensure that when both text and parts are present, no content is included in the text that isn't found in a part.
family string SHOULD be present Family name (often called 'Surname')
given string SHOULD be present Given names (not always 'first'). Includes middle names. This repeating element order: Given Names appear in the correct order for presenting the name
prefix string MAY be present Parts that come before the name. This repeating element order: Prefixes appear in the correct order for presenting the name
suffix string MAY be present Parts that come after the name. This repeating element order: Suffixes appear in the correct order for presenting the name
period Period MAY be present Time period when name was/is in use

Unstructured Names

text

Text representation of the name. This can be used if a structured name as detailed below cannot be supported. It MAY be present in addition to a structured name.

Structured Names

Structured names SHOULD be used whenever possible as detailed below.

The following elements SHOULD be used to construct structured names:

Element Example
family smith
given John
prefix Mr
suffix MBE