Виды профиля для гкл: все виды, выбор, стоимость, производители

Профиль для гипсокартона: виды и способы монтажа

Профиль для гипсокартона служит для создания каркаса, на который крепится строительный материал. Профиль может различаться по сечению, размерам и конфигурации. В статье будут рассмотрены основные требования к профилю для гипоскартона, описаны виды профилей и область их применения, а также способы монтажа профиля.

Требования к профилю для гипсокартона

Профиль для гипсокартона представляет собой металлические элементы, из которых собирается каркас для крепления листов гипсокартона. Элементы профиля разделяются на металлические балки, подвесы и крепежные элементы. Профиль должен отвечать следующим требованиям:

• гипсокартонный профиль изготавливается из металла, который менее подвержен или полностью защищен от образования коррозии;
• толщина металлических балок больше 0,5 мм. Тонкостенные элементы не способны выдержать вес конструкции, со временем листы провисают или вовсе отходят;
• углы металлических элементов должны быть прямыми, без изгибов и сколов;
• профиль не должен гнуться и изменять форму под действием силы;
• металлический профиль должен выдерживать вес гипсокартонных листов, не должен прогибаться под весом конструкции, быть прочным и долговечным.

Виды профилей и область применения

Гипсокартонные профили классифицируют по способу применения, по форме, по особенностям конструкции и по области применения. Рассмотрим классификацию более подробно.

По способу применения гипсокартонные профиля разделяются:

1. фиксация гипсокартона на потолке;
2. фиксация гипсокартона на стене.

В делении по способу применения имеются следующие разновидности:

1. металлические профили, применяемые для обшивки плоскости;
2. металлические профили, используемые для создания конструкции перегородки в квартире.

Кроме этого, профиля различаются по форме:

1. круглые;
2. плоские;
3. по форме швеллера;
4. угловые.

Обычно профили изготавливают из оцинкованной стали, в зависимости от конструкции используют толстоволокнистый или тонковолокнистый металл.

Рассмотрим виды профилей для гипсокартона подробней, чтобы понять предназначение этих элементов.

Профиль для установки основного каркаса. Чтобы установить основной профильный каркас потребуются следующие виды профилей:

• UD профиль для создания основы конструкции. На них будут фиксироваться остальные элементы, такие как перегородки, гипсокартон. Такой профиль изготавливается из толстоволокнистой стали.
• CD профиль для обеспечения жесткости конструкции. На CD профиля крепятся листы гипсокартона, поэтому они также изготавливаются из толстоволокнистого металла.
• Профиль арочного типа. Отличается наличием перфорации на поверхности металла, что позволяет изгибать металлические элементы для создания сложных конструкций.

Профиль для перегородок. Для данного типа профилей также существует разделение:

• UW профиль для обшивки конструкции;
• CW профиль. Представляет собой стойки, обеспечивают жесткость конструкции, гипосокартон на такие профили можно фиксировать с двух сторон.

Способы монтажа профиля для гипсокартона

Способы монтажа профиля для гипсокартона различаются только способом крепления конструкции. В начале работы необходимо расчертить макет конструкции, купить нужные детали, после этого начать сборку. После этих шагов, выбирают способ крепления профиля. К способам крепления профильной конструкции относят:

• Применение специального крепежа. Это самый правильный из всех способов, так как его рекомендуют производители профилей. Сложным считается просчет конструкции и наращивание профильных опор. Соединение происходит за счет специальных боковых соединителей. Можно использовать шуруповерт с саморезами в качестве дополнительного способа крепления.
• Крепление профилей саморезами. Данный способ является самым популярным, несмотря на то, что надежность крепления ниже, чем у первого способа.

• Крепление при помощи просекателя. Крепление профиля происходит за счет инструмента, просекателя. Он делает отверстия в металле, при этом изгибает металл, тем самым создает надежное соединение двух элементов. В труднодоступных местах просекатель не может скрепить детали, там лучше воспользоваться шуруповертом. Скрепление деталей просекателем очень прочное, поэтому исправить недочеты не получится, перед применением тщательно обдумайте свои действия.

Профили для гипсокартона обеспечивают несущую конструкцию, они служат для крепления листов строительного материала. Профили разделяются на разные виды, в зависимости от нужной конструкции. Выполняя сборку профилей, важно выполнять работу поэтапно, не забывая соблюдать разметку конструкции. В статье были рассмотрены требования к гипсокартонному профилю, описаны его виды и область применения, а также способы монтажа конструкции.

07.11.2019

Подписаться на рассылку

классификация и название, назначение, видео и фото

Различные гипсокартонные конструкции создаются при помощи каркаса из металлических профилей. Они выпускаются различными по форме, размерам, назначению. Для определения нужного вида профиля следует разобраться с его предназначением, размерами. Виды изделия для гипсокартона предназначены для их конкретного применения, поэтому следует ознакомиться с каждым типом в отдельности.

 

Виды профилей, применяемых для создания каркаса под гипсокартон

Монтаж каркасной основы из метал-профилей по своей конструкции несложный. Он состоит из вертикалей и горизонталей составляющих металлические элементы, которые называются направляющими, потолочными, перегородочными профилями. Для правильного выбора нужного профиля, следует ознакомиться с его маркировкой и размерами.

Профиль стоечный для каркаса ГКЛ

Какие существуют профили для гипсокартона:

Название профиля без сокращений	Сокращенное название на Российском рынке	Сокращенное Европейское название
Стоечный	ПС	CW
Направляющий	ПН	UW
Потолочный	ПП	CD
Потолочный направляющий	ПНП	UD

Какие основные профили для гипсокартона бывают?

Назначение и характеристики направляющего профиля (ПН)

Профиль направляющий, сокращенно ПН он же UW.  Толщиной 0.55-0.8 мм.  Это защищает изделие от окисления металла, а также от поражения его ржавчиной. По внешнему виду ПН произведен в виде планки буквой «П», которая применяется в сооружении металлического скелета для фальш-стен. Применяется для быстрого возведения перегородок различной толщины. Направляющие служат основой в монтаже каркаса, создают прочность конструкции. Профиль имеет разную ширину, что позволяет возводить высокие перегородки и прятать в стене коммуникации.

Направляющий профиль, применим для каркаса для гипсокартонной фальш-стены

Размеры направляющего элемента для гипсокартона:

 

Маркировка изделия	Толщина, мм.	Ширина, мм.	Высота ребра, мм.	Длина, м.
UW (ПН)-2-50*40	0.5	50	40	3
UW (ПН)-4-75*45	0.5	75	45	3
UW (ПН)-6-100*40	0.6	100	40	4

В профиле заводом-изготовителем могут быть сделаны отверстия 8 мм. для крепления изделия к основе (стена, потолок). Крепежными элементами, в основном, служат дюбель-гвозди размером 6/40, 6/60. Длина изделия достигает 3 метров.

В монтаже перегородки, выравнивании стены гипсокартоном первым крепится данный вид металлического изделия по сделанной заранее разметке. Затем применяются ПС (стоечный), а также дополнительные материалы, такие как подвесы, удлинители, крабы.

Обозначения и размеры UD профиль

Функциональность стоечного профиля (ПС)

Расшифровывается как профиль стоячный, кратко ПС или другое европейское обозначение CW. Данный вид металлической планки применяется при производстве металлического каркаса для гипсокартонной фальш-стены, а также выравнивание вертикальных поверхностей в помещении. Осуществляя возведение каркаса для фальш-стены, металлический элемент вставляется в зафиксированный НП. В связи с этим, ширина ПС и ПН имеет одинаковые размеры. Перегородочный профиль для гипсокартона производится из оцинкованной стали.

 

Маркировка изделия	Толщина, мм.	Ширина, мм.	Высота, мм.	Длина, м.
CW (ПС) 50*50	0.4-0.6	50	50	2.6; 3; 4
CW (ПС) 65*50		65
CW (ПС) 75*50		75
CW (ПС) 100*50		100

Профиль стоечный применим для создания каркаса перегородки из гипсокартона

В зависимости от создаваемой конструкции приобретается требуемый размер. Длина может быть от 3 до 4 метров. Отличительной чертой профиля являются специальные канавки для удобства монтажа гипсокартонных листов, а также их фиксации.

Размеры профилей CW

Применение, размеры потолочного направляющего профиля (ПНП)

Обозначается так же как ПН (UD) (расшифровка — профиль направляющий потолочный). В сечении П-образный, с гладкими боковыми стенками. Используется как основа-опора для стоек и перемычек. Крепится по периметру конструкции, в него потом устанавливаются все остальные элементы системы. ПНП производится из металла, покрытой защитным слоем. Он применяется в производстве металлической основы для подвесного потолка из ГКЛ. Данный элемент крепится к стене дюбель-гвоздями, служит для дальнейшей вставки в них потолочного профиля и создает прочность всей конструкции под гипсокартон.

Потолочный направляющий профиль создает металлическую конструкцию для подвесного потолка из ГКЛ

Профиль для гипсокартона потолочный имеет такие размеры: толщина ПНП 28*27 – 0.4-0.6 мм., ширина 28 мм., высота – 27 мм., длина – 3 метра.

Потолочный профиль (ПП)

Пожалуйста самый популярный в каждом ремонте это потолочный профиль (ПП) или другое обозначение CD.  Это изделие применяется в монтаже металлического каркаса для подвесного, фигурного, многоуровневого потолка из гипсокартона. Профиль вставляется, при монтаже, в направляющий и крепится к подвесам. Производится изделие из оцинкованной стали, что дает защиту от ржавчины.  Для потолочного профиля применимы специальные саморезы, называемые мастерами «клопы» – диаметр – 3.5-3.9 мм. длина 9.5-11мм.

Потолочный профиль монтируется в каркас для подвесного потолка

Размеры потолочного профиля для гипсокартона: толщина 0.4-0.6 мм., ширина – 60мм., высота 27мм., длина  стандарт 3 метра на заказ  4 метра.

Дополнительные виды профилей

А также производятся виды профилей для гипсокартона, применяемые в возведении металлического каркаса не так часто, и в основном заменяемые собственно ручным производством.

Арочный профиль

Данный гипсокартонный арочный профиль применяется в создание арок и других фигурных элементов на потолке или на стене. В основу производства арочного профиля лег потолочный метал-элемент. Подробно, о видах арочного профиля.

Арчный профиль пригоден для создания каркаса арок из ГКЛ, а также фигурных элементов под гипсокартон

Заводы изготовители предлагают свои варианты  изгибания  профиля для арок на заказ, имеющего отличительные  удобства в работе. Для этого используют обычный ПП (60х27) после изгибания обозначается как ПА.

Размеры радиуса для изгиба:

Маркировка изделия	Толщина, мм.	Ширина, мм.	Высота, мм.	Длина, м.	Радиус загиба, мм.
ПА(CD) – 60×27 KNAUF	0/4-0/6	60	27	2.6; 3; 4	1000
ПА(CD) – 60×27 KNAUF  (внутр.)			27		500

Изогнутый профиль

Подробно, о других вариантах изготовления арок.

Усиленный профиль

Данный элемент обозначается UА.  Изделие используется для усиления каркасной основы для гипсокартона. Он применим в подвесных потолках сложной конструкции, а также в формировании перегородок с отяжелением предметов (подвесить телевизор на поверхность перегородки), создание в гипсокартонных перегородках проемов дверей, окон.

Усиленный профиль монтируется в места каркаса, где предполагается навешивание тяжелых предметов на гипсокартонную основу

Размеры усиленного профиля под гипсокартон:

маркировка изделия	толщина изделия	спинка профиля, мм.	высота ребра, мм.	кол-во рядов просечек на спинке	стандартная длина профиля, м.
UA–50-40-2	2.0 мм.	50	40	1 шт.	2.6; 3; 4
UA-75-40-2		75		2 шт.
UA-100-40-2		100
UA-125-40-2		125
UA-150-40-2		150

Для защиты наружных углов

Маркируется ПУ. Данный вид для ГКЛ предназначен для обшивки углов от различных механических воздействий (удара) гипсокартонного изделия. Профиль имеет перфорацию, для лучшей фиксации к поверхности при использовании шпаклевки.  Имеет такие размеры:

Обозначение	Толщина, мм.	Ширина полочки, мм.	Материал изготовления	Длина профиля, мм.
ПУ 20-20	0.22-0.25	20	аллюминий	3
ПУ 25-25	0.4	25	оцинкованная сталь
ПУ 30-30	0.4	30
	0.5
ПУ 35-35	0.5	35

Монтаж профилей

Для создания металлического каркаса следует применить профили и их комплектующие для того чтобы каркасная основа под гипсокартон была прочной и прослужила долгий эксплуатационный срок.

Для того чтобы порезать оцинкованный профиль используются ножницы для резки металла. Если резать профиль болгаркой, тогда при больших оборотах круга металл нагревается, тем самым портится антикоррозийное покрытие. Края профиля остаются незащищенными. Это крайне нежелательно при монтаже каркаса в ванных комнатах, а также на балконе – где есть повышенная влажность. Правила работы и секреты работы с ГКЛ.

Схема крепления ГКЛ профилей

Направляющие профили крепятся к основанию (потолок, пол, стена) только при помощи дюбель-гвоздей. Размер крепежа зависит от нескольких факторов: материал основания, сложность металлической конструкции. Крепежи должны располагаться на расстоянии 25-30 см.

Подвесы для профилей крепятся на одной линии с профилем через каждых 40-60 см. минимальное расстояние берется в том случае, если предполагается большая нагрузка на гипсокартонную поверхность. Кроме того, для укрепления каркаса из стоечных профилей создается усиление, проходящее в месте утяжеления конструкции.

Для шумо, -звукоизоляции применяется уплотнительный материал, выбор которого зависит от места, уровня влажности, пожаробезопасности.

Выбирая профили для изготовления каркаса, следует помнить не только о правилах применения, но так же следует обращать внимание на фирму-производителя. Такие профили для гипсокартона, как «KNAUF» производятся размерами согласно всем гостам, придерживаясь всех технических характеристик.

Подробно о быстром способе возведении перегородок в квартире.

Видео:

Видео:

Видео:

Профиль для гипсокартона размеры, виды и технические характеристики

Для создания конструкций из ГКЛ подразумевающих «сухое» выравнивание поверхности, а также выполняющих маскировочную для коммуникаций и проводки функцию, используют каркасную систему облицовки. Основой каркаса могут быть деревянные бруски, подходящей толщины, но куда более целесообразно использовать металлические профили для крепления гипсокартона.

О чем эта статья

Что такое металлопрофиль

Каркасные профили — это тонкие металлические изделия, которые делают из оцинкованного листа, раскатанного холодным методом, алюминия или пластика.

Обычно они имеют Т-, Г- или П-образную форму с полостями. Различают профили для гипсокартона:

• Угловые;
• Плоские;
• В форме швеллера.

Применяются в качестве несущих элементов для ГКЛ при:

1. Создании уровневых потолков;
2. укреплении гипсокартонных кромок;
3. формировании «скелета» криволинейных конструкций, арок;
4. монтаже перегородок;
5. обшивке стен, потолков со значительными перепадами на поверхности;
6. внутреннем настенном либо потолочном утеплении, звукоизоляции

Качество всех видов профилей для гипсокартона устанавливают нормы ГОСТа и ТУ.

Производством длинномеров занимается огромное количество фирм, в частности такие известные как — Кнауф и Гипрок.

Существует множество разновидностей металлопрофиля, в которых очень важно разбираться и правильно уметь их выбрать, в противном случае, при монтаже «из чего попало», получается неровная, непрочная поверхность либо напротив — нецелесообразно жесткая и чрезмерно дорогостоящая.

Основные виды профилей

Изделия классифицируются на следующие типы:

• Направляющие или стартовые;
• Потолочные стоечные;
• Стоечные настенные/перегородочные;
• Усиленные;
• Арочные;
• Маячковые;
• Угловые — защитные и штукатурные;
• Направляющие.

Направляющие

Направляющие — это виды профилей для гипсокартона, образующие по периметру раму каркаса. Они крепятся непосредственно к базовому покрытию и служат фиксационным основанием для стоечных настенных и потолочных длинномеров. Могут быть выполнены из стали либо алюминия.

Стартовые потолочные направляющие для гипсокартона — ППН или в европейской маркировке UD. В их пазы вставляются CD профили для гипсокартона. Они обладают гладкими спинками и профилированной полкой. Могут быть с заводскими отверстиями под крепежи.

Основные параметры юд-профиля:

• Длина — 3 м
• Ширина полки — 27 мм
• Длина каждой спинки — 28 мм
• Толщина — 0,4-0,55 мм

UW (ПН) — настенные, перегородочные направляющие для гипсокартона. Их назначение — поддержка CW. UW, выпускаются в широкой размерной линейке:.

• 50×40 мм
• 75×40 мм — применяется как перемычный в каркасах
• 100×40 мм

В спинках часто имеются отверстия под 8 мм дюбели.

Длина — 2, 75 м, 3 м, 4 м, 4,5 м и 6м

ЮВ профиль под гипсокартон, иногда используется также для создания многоуровневых потолочных конструкций.

Потолочные стоечные

Потолочные — применяются для изготовления горизонтальных частей каркасов потолка. На каждой торцевой полке по 3 ребра жесткости. Монтируются на подвесы п-образного типа и входят в пазы UD, к которым фиксируются, после выравнивая при помощи нитей-подвесов.

Маркируются как CD.

Стандартный размер сд — ширина 6 см, высота спинок — 2,5 см. Ходовая длина — 3 — 4 м, но также они бывают 2,75 м и 4,5 м. Толщина стали — 0,4-0,55 мм.

Стоечные настенные/перегородочные

Стоечные несущие — так называются швеллеры, верхняя кромка которых, имеет С-образную форму. Монтируются в подсистеме ГКЛ, в качестве стоек, основных «скелетных» элементов вертикального либо перемычного типа, а также служат как полостная область для укладки теплозвукоизоляционных материалов, прокладки коммуникаций. Европейская маркировка CW, российская — ПС.

ПС фиксируется по длине через 40-60 см к п-образным подвесам при помощи саморезов и к направляющим — дюбелями.

Стандартные размеры стоечного профиля под гипсокартон:

• Длина полки — 5 см
• Ширина спинки — 50 мм, 65 мм, 75 мм, 100 мм
• Общая длина — 2,75 м, 3,5 м, 3 м, 4 м, 4,5 м, 6 м

Но при этом, реальные размеры спинки, могут отличаться от указанных, на 1,5-2 мм.

Как правило, стойки обладают тремя продольными канавными секциями по всей длине — та, что в середине находится на стыковке ГКЛ-листов, по обе стороны от нее — указывают саморезную центровку.

Усиленные

Усиленные — UA, применяются как стойки дверных каркасных систем, а также при формировании остова для значительных несущих нагрузок, так технические характеристики профиля для гипсокартона усиленного типа, позволяют фиксацию с помощью дюбелей, вещей со значительным весом — полок, шкафов-пеналов, телевизоров и так далее. Они обладают значительной толщиной — 2 мм, повышенной устойчивостью к коррозии.

Основные размеры усиленного профиля для гипсокартона:

• Длина — 3 метра, 4 метра, 6 метров
• Высота полок — 4 см
• Ширина спинок — 5 см, 7,5 см, 10 см

Угловые

Угловые — ПУ, монтируются на угловых частях конструкций и делятся на:

• защитные, длиной 3 метра и сечениями — 25×25, 31×31 с толщиной 0,4 мм и 31×31 с толщиной 0,5 мм
• штукатурные угловые профиля для гипсокартона с сеткой, пластиковые, длиной 3 метра и сечением 35×35

Угловые элементы выполняют одновременно защитную роль и облегчают оштукатуривание, за счет перфорированного покрытия, а также сетки как во втором варианте.

Маячковые

Маячковые профили — ПМ, виды профилей для гипсокартона, использующиеся как уровневая направляющая при оштукатуривании поверхностей. Они делаются из оцинкованного металла — стали либо пластика, обладают высокими антикоррозийными свойствами. Длина ПМ — 3 метра, их стандартные сечения — 22×6, 23×10, а также 62×6,6.

Этот элемент практически незаменим в местах, где требуется идеально гладкое оштукатуривание ГКЛ.

Арочные

Арочные профиля для гипсокартона — гибкие оцинкованные элементы, изготовленные из ПП 60×27. Их сфера — создание криволинейных элементов, арок, колонн и так далее. Могут иметь вогнутую форму (с длиной 3 метра, радиусом изгиба 0,5 м) либо выпуклую (с длиной 6 метров, радиусом изгиба 1 м).

Вместо них не редко берут и обычные ПП, снабжая их нарезкой, при помощи ножниц по металлу, по всей длине для облегчения сгибания. Однако новичкам лучше все-таки начинать со специализированных элементов.

Советы по выбору профилей

Из сказанного ранее, понятно, что для каждой части каркаса, существует различные виды профилей для гипсокартона, обладающие при этом, еще и широкой размерной линейкой. Но какой профиль выбрать из, казалось бы, совершенно одинаковых по габаритам и назначению?

1. По покрытию. Самые популярные швеллеры — оцинкованные. Если посмотреть из чего состоит покрытие в техническом паспорте производителя или выписки к изделию, можно заметить, что некоторые из них, состоят из цинка даже менее чем на 30%, хотя по-настоящему качественный профиль содержит до 99% этого вещества.
2. Окрашенные. Окрашенные длинномеры в строительстве очень популярны, Казалось бы, краска способствует усилению защиты металлического изделия, однако стоит присмотреться, для чего она предназначена на самом деле. Возможно, нанесена она для маскировки дефектов. Некачественное покрытие обычно облазит во время монтажа.
3. По толщине. Толщина металла для стандартной конструкции может быть 0,5 мм. Однако для каркасов, требующих большую прочность основания, рекомендуется выбирать большие параметры. Для этого изначально определите, какую функцию будет выполнять каркас и сколько полезной нагрузки предполагает.
4. По перфорации. Перфорированная накатка нередко выполняется недобросовестными производителями, лишь для сложности визуального определения толщины профиля.
5. По жесткости. В качественных, прочных изделиях, ребра жесткости располагаются по всей длине.

Если швеллер при сжатии в руке сгибается — лучше брать более жесткий.

Знать, как правильно выбрать составляющие каркаса — половина успеха в создании надежной, долговечной конструкции.

Профиль для гипсокартона: виды, характеристики и применение

Монтаж гипсокартона требует сборки прочного и жесткого каркаса. Для этого применяются деревянные бруски и другие подсобные материалы. Самый удобный в работе материал – металлические профили. Они прочные и не подвержены коррозии. Рассмотрим представленные на рынке материалы и их особенности.

Для монтажа каркаса понадобятся следующие элементы:

• направляющие элементы фиксируются непосредственно к основным стенам помещения, они определяют будущий периметр конструкции;
• стоечные профили устанавливаются непосредственно в направляющие, фиксируются по всей площади стен и несут основную нагрузку;
• потолочные элементы крепятся на верхней части каркаса, если гипсокартоном обшиваются не только стены;
• перегородочные профили служат для усиления конструкции, обеспечивают надежную фиксацию других элементов между собой;
• для оформления дверных проемов применяют арочные элементы, форма и размеры которых могут меняться.

Профили для гипсокартона производятся из холоднокатаной стали, которая проходит процедуру цинкования. Это делает материал износостойким и долговечным, его можно использовать внутри помещения и снаружи.

Сборка каркаса не требует специальных знаний и инструмента. С этим может справиться даже новичок, главное – правильно рассчитать количество материалов: профилей, дополнительных элементов и крепежа.

Направляющий элемент

При монтаже каркаса в первую очередь устанавливают направляющие профили для гипсокартона. Изделия с П-образным сечением выполнены из качественной стали, поставляются отрезками длиной 3 метра. Допускается стыковка отдельных элементов в единую конструкцию. К достоинствам продукции данного типа относятся:

• механическая прочность и жесткость, сломать его достаточно трудно;
• тонкий оксидный слой цинка, который защищает металл от коррозии и окисления;
• при монтаже профили пробиваются дюбелями или саморезами насквозь, что не сказывается отрицательно на характеристиках продукции;
• изделия сохраняют свою форму и геометрию при высоких нагрузках;
• благодаря небольшому весу сборка изделий не вызывает затруднений.

Установка направляющих металлических профилей для гипсокартона является первым этапом монтажа. При сборке важно соблюдать уровень вертикальных и горизонтальных планок, для того чтобы каркас был не только жестким, но и идеально ровным.

Стоечный профиль: характеристики и применение

Стоечный профиль выпускается в нескольких вариантах. В зависимости от типа каркаса и требований к нему меняются размеры полок и основания, сечение и толщина металла. Чаще всего стенки изделий делаются ребристыми. Такая форма обеспечивает дополнительную жесткость и облегчает монтаж.

К достоинствам стоечных элементов для каркаса можно отнести:

• широкий диапазон использования, продукция применяется для организации каркасов различного размера, формы и назначения;
• высокие показатели прочности и жесткости, при соблюдении правил монтажа и установке перегородок конструкция может выдержать большие механические нагрузки;
• защищенность от воздействия влаги и сырости, можно устанавливать снаружи;
• несколько вариантов исполнения, возможность подобрать металлический профиль для создания конструкций различного назначения.

Стоечный профиль – обязательный элемент любого каркаса для гипсокартона. Чтобы подобрать оптимальный размер и толщину профиля, нужно рассчитать величину нагрузки. Сделать это нужно до начала монтажа.

Потолочный элемент каркаса

Если планируется отделать гипсокартонными листами потолок помещения, используются соответствующие изделия. Их установка также осуществляется на направляющие, дополнительно выполняется фиксация элементов к потолку помещения. Для соединения между собой применяются перегородки.

Потолочные профили по своей конструкции идентичны стоечным элементам. Достоинства продукции также не отличаются. К плюсам изделий можно отнести небольшой вес, высокие показатели прочности и жесткости, надежную защиту от воздействия коррозии и окисления, простой монтаж за счет ребристой формы основания. Продукция отличается доступной ценой.

Дополнительные детали каркаса

В простых случаях, если каркас не требует большой жесткости, монтаж осуществляется на саморезы или дюбели. Размеры метизов определяются техническими требованиями и особенностями основных стен и потолков. В большинстве ситуаций монтажникам требуется приобрести дополнительные элементы, в качестве которых могут применяться:

• двухуровневые соединители для фиксации стоечных и потолочных профилей к основным стенам здания, изделия перед установкой сгибаются и принимают П-образную форму;
• для установки подвесных потолков используются специальные подвесы, их особенностью является возможность регулировки величины выноса;
• если потолочные элементы устанавливаются на большом расстоянии от основной конструкции, применяют анкерные подвесы с длиной тяги до 1 метра;
• соединители типа «Краб» используются для надежной фиксации двух элементов во взаимно перпендикулярных направлениях;
• в качестве метизов могут использоваться саморезы, в том числе с нейлоновыми шайбами, дюбеля, анкер-клины и другая продукция.

До начала монтажа каркаса под гипсокартон необходимо предварительно спланировать контуры будущего “скелета”, рассчитать количество и вид материала, дополнительных элементов и крепежа. После покупки комплектующих устанавливаются направляющие профили, затем стоечные и потолочные элементы. Между собой профили соединяются перегородками, усиливая конструкцию. После завершения подготовительных работ установка гипсокартона занимает минимум времени.

Виды профилей для гипсокартона: подробный обзор существующих профилей

Современный ремонт в наши дни трудно представить без сооружения гипсокартонных конструкций, которые нашли свое идеальное применение в отделке помещений. Каждая работа с использованием гипсокартоных материалов предполагает возведение основного несущего каркаса, сооружаемого из металлических профилей, что придает всей конструкции повышенную прочность и надежность, чем при креплении гипсокартонных листов на клей.

Поэтому для сооружения разных конструкций соответственно выбирают и металлопрофили.

Краткое содержимое статьи:

Классификация гипсокартонных профилей

Металлические профили для фиксации гипсокартонных листов могут различаться между собой по функциональной нагрузке, особенностям конструкции и ореолу использования.

По предназначению различают стеновые и потолочные профили. Кроме того, их классифицируют следующим образом: одни применяются для обшивки основного каркаса, другие – для создания перегородок.

По форме они бывают: плоские, угловые, или в виде швеллера. Сырьем для производства служит тонколистовая или толстолистовая оцинкованная сталь.

Достоинства оцинкованной стали

Основным достоинством оцинковки считается длительный срок эксплуатации, даже в условиях влажной среды, так как цинковое покрытие стальной поверхности надежно защищает изделие от возможной коррозии. В результате чего её прекрасно используют в качестве покрытия для кровли.

В отличие от деревянного каркаса оцинкованный не подвержен воздействию различных насекомых, устойчиво сохраняет первоначальную форму даже по истечению долгого времени.

Профили для основного каркаса

В целях формирования каркаса для последующей обшивки гипсокартоном используют следующие виды профиля:

Направляющие, маркировка которых обозначается буквами UD, традиционно производятся из толстолистового стального проката, чтобы выдержать определенную нагрузку от листов гипсокартона, готовый каркас из профилей определяет габариты и очертания окончательного варианта конфигурации помещения.

Несущие, маркировка обозначается как CD, фиксируются к металлопрофилю основного каркаса с маркировкой UD и предназначаются для выполнения несущей функции. Изготавливаются из такой же стали, как и UD.

Арочные (гибкие), оснащены усиленной перфорацией из большого количеств прорезей и отверстий, что способствует его изгибу в разных направлениях и под разным углом при обустройстве разнообразных конфигураций. Например, арочных сводов или многоуровневых потолочных систем.

Угловые, также оснащены перфорацией и усиливают прочность наружных углов стен, дверей или окон.

Профили для перегородок

Для сооружения перегородок рекомендуют использовать профили, схожие по классификации с предыдущими:

• направляющие, маркировка – UW: используют для обшивки стен гипсокартонными листами в различных конфигурациях и регулируемом простеночным периметром;
• стоечный, маркировка – CW: усиливает степень жесткости каркаса за счет вертикальных стоек, при этом гипсокартон монтируется с двух сторон,а также в качестве перемычек.

На фото можно рассмотреть все классификации профилей для гипсокартона.

Размерный ряд профилей

В зависимости от функционального предназначения различают профили разных форм и габаритов. Так, размеры профиля для гипсокартона могут быть:

• 0,25-0,28х300-400 см (толщина стенки от 0,5 до 0,7 мм) – для направляющих с маркировкой UD;
• 0,25-0,28х300 см или 0,28х400 см (высота полки от 0,5 до 0,6 мм) – для несущих с маркировкой CD.

Для изделий длиной 3,0 м вес профилей составляет от 1,2 до 1,8 кг, 4,0 м – от 1,6 до 2,4 кг в зависимости от толщины стального проката.

Более широкие профили используют для перегородок:

• для UW: 50, 75 и 100 мм при длине 3,0 или 4,0 м и приблизительном весе одного элемента от 2,19 до 3,88 кг;
• для CW: 48,8х3000(4000)х50, 73,8х3000(4000)х50, 98,8х3000(4000)х50 при толщине металла 0,5-0,6 мм.

Детали крепления

Крепежная фурнитура используется для надежной фиксации профилей к железобетонным поверхностям. С их помощью прочно соединяются отдельные элементы каркасных конструкций и крепятся листы гипсокартона к профилям. Детали крепления классифицируются следующим образом: тяги, кронштейны и подвесы.

Фото профилей для гипсокартона

Также рекомендуем просмотреть:

Помогите сайту, поделитесь в соцсетях 😉

Размеры всех видов профилей для гипсокартона

• Основные виды профилей для гипсокартона
• Крепеж и дополнительные элементы

Любой специалист, ознакомившись с проектом конструкции из гипсокартона, задается вопросом – какие материалы потребуются при изготовлении ее каркаса. Естественно, для «знающего» человека решение этой задачи не составит абсолютно никакого труда, но как быть начинающему домашнему мастеру? Мы решили помочь умельцам, которые будут собирать каркас впервые, рассмотрев в нашей статье разновидности профиля для гипсокартона и его размеры.

1 — UD; 2 — CD; 3 — CW; 4 — UW

Отметим, что рассказ только о видах металлопрофилей для гипсокартона, как об одном элементе конструкции, на наш взгляд, не принесет особой практической пользы. Поэтому мы решили добавить сюда описание крепежа и сопутствующих материалов, применяемых при различных способах монтажа каркаса.

Основные виды профилей для гипсокартона

Этот, без сомнения, основной элемент конструкции, имеет несколько разновидностей, четыре из которых предназначены для сборки каркаса и выполнены из тонкой стали методом холодного проката.

Направляющий – ПН (англ. UW)

Используется при создании перегородок и отделки стен, являясь направляющей, к которой крепятся стойки. Этот стеновой профиль для гипсокартона имеет следующие размеры (мм):

• длина – 3000;
• высота полки (боковой части) – 40;
• ширина спинки (основания) – 50; 65; 75; или 100.

В спинке проделаны 8 мм отверстия под дюбели.

Стоечный – ПС (CW)

Является основным элементом обрешетки стен и перегородок. Крепится в направляющей, расположенной по периметру рабочей зоны. Отличается тем, что верхние края его боковых частей имеют С-образную форму. Наиболее распространенные следующие размеры стоечного металлического профиля для гипсокартона (мм):

• длина – 3000; 3500; 4000 и 6000;
• высота полки – 50;
• ширина спинки (аналогична этому показателю у ПН) – 50; 65; 75 или 100.

Потолочный – ПП (CD)

Используется при работах по монтажу потолочных конструкций. Отличается от стоечного тем, что крепится к потолку с помощью специального крепежа. Боковины и основание («канавки») — ребра жесткости, которые придают ему дополнительную прочность. Стандартные размеры потолочного профиля (мм) такие:

• длина – 3000;
• высота полки – 27;
• ширина спинки – 60.

Направляющий потолочный – ПН (UD)

Разработан специально для создания потолочных каркасов, служит направляющим «основанием» всей конструкции. Его боковые части имеют продольные гофры, которые придают ему необходимую жесткость, а основание оборудовано отверстиями под крепежные дюбели. Направляющий потолочный профиль под гипсокартон имеет размеры (мм):

• длина – 3000;
• полка – 27;
• спинка – 28 мм.

Помимо этих разновидностей существуют особые элементы каркасной конструкции, которые могут ее усилить, обеспечить защиту, облегчить отделку или придать ей «изогнутую» форму.

Усиленный – UA

Используется в качестве стоек при монтаже дверных проемов в перегородках, изготавливается из качественной стали, обладающей повышенной стойкостью к коррозии. Стандартные размеры усиленного стоечного профиля для гипсокартона (мм):

• длина – 3000, 4000, 6000;
• высота боковых частей – 40;
• ширина основания – 50, 75, 100;
• толщина заготовки – 2.

Угловой – ПУ (защитный)

Деталь монтируется на внешних углах конструкции, являясь их защитой от возможных повреждений во время эксплуатации. Полки элемента оборудованы отверстиями, в которые проникает отделочный раствор (шпаклевка или штукатурка), обеспечивая более прочный контакт с поверхностью. Размеры угловых металлических профилей для гипсокартона (мм):

• длина – 3000;
• сечение – 25х25х0,4;
• 31х31х0,4;
• 31х31х0,5.

Угловой – ПУ (штукатурный)

Крепится на углах проемов, торцах перегородок и других поверхностей, которые будут оштукатуриваться. Так же, как и защитный, он имеет отверстия для проникновения отделочных растворов (предварительно нанесенных на угол конструкции) и выполняется из оцинкованной стали, стойкой к коррозии. Стандартные размеры штукатурного профиля для гипсокартона (мм):

• длина – 3000;
• сечение – 35х35.

Маячковый – ПМ

Используется как опорная направляющая база в целях получения более ровной поверхности при отделочных работах по оштукатуриванию. Материал изготовления – оцинкованная сталь высокого качества, имеющая отличные антикоррозийные свойства. Среди современных специалистов по ремонту жилых и производственных помещений наиболее распространен маячковый профиль для ГКЛ следующих размеров (мм):

• длина – 3000;
• сечение – 22х6, 23х10 и 62х6,6.

Арочный – ПА

Чаще всего этот элемент изготавливают из ПП 60/27, описанного нами в одном из предыдущих разделов статьи. Он бывает двух видов и используется при монтаже каркаса для нестандартных «криволинейных» потолочных конструкций на основе ГКЛ, а также арок, колонн и куполов из этого материала. Основное отличие изделия: при необходимости его можно легко согнуть плавной дугой. Арочный профиль под гипсокартон имеет размеры (мм):

• длина «вогнутого» – 3000;
• «выпуклого» — 6000;
• радиус изгиба (мин.) «вогнутого» — 500;
• «выпуклого» — 1000.

Следует отметить, что профессиональные и опытные мастера, занимающиеся отделкой помещений с применением ГКЛ, используют в своей работе только проверенные и хорошо зарекомендовавшие себя материалы.

Одним из стандартов качества является продукция немецкой компании KNAUF, по классификации которой и был подготовлен этот обзор. Все вышеперечисленные виды и размеры металлопрофилей для гипсокартона вы без труда сможете найти под фирменным логотипом этой известной марки.

К содержанию↑

Крепеж и дополнительные элементы

Помимо описанных элементов, при монтаже каркаса и закреплении его основы к перекрытиям используются некоторые стандартные детали, которые необходимо подготовить перед выполнением работы:

• Подвес прямой – крепит потолочный (ПП) и стоечный (ПС) профиля для гипсокартона к стене и потолку (рисунок 1).
• Подвес анкерный – крепят ПП к потолку, имеют зажим и тягу, которые позволяют регулировать положение конструкции по высоте (рисунок 2).
• Удлинитель – используется при стыковке (соединении) полос металлопрофиля в различных комбинациях (рисунок 3).
• Одноуровневый соединитель «краб» — может соединять все виды металлических профилей для гипсокартона в крестообразных (строго 900) элементах конструкции. Чаще всего применяется для скрепления ПП в одном уровне при монтаже обрешетки на потолке (рисунок 4).
• Двухуровневые соединители – крепят полосы ПП перпендикулярно друг другу в разных уровнях (рисунок 5).
• Анкерные дюбеля и самонарезающие шурупы – с их помощью все элементы каркаса из металлопрофиля скрепляются между собой и надежно фиксируются к основным перекрытиям помещения (рисунок 6).

Заключение

Как видно из нашего исследования, в таком, непростом на первый взгляд, деле, как обустройство конструкции из ГКЛ, все продумано и рассчитано до мелочей. Стоит только иметь желание и запастись терпением – результат превзойдет все ожидания. Дерзайте, а если возникнут вопросы по способу монтажа каркаса, виду или размеру профилей под гипсокартон – смело обращайтесь к нам, здесь вы получите квалифицированную и грамотную помощь.

Автор статьи

47 лет

стаж внутренних отделочных работ 21 год.

Поделись статьей с друзьями:

какие профиля нужны для перегородок, стен и потолка

Популярность гипсокартона в значительной степени связана с удобством применения легкого и прочного металлопрофиля, который является основой для крепления листов. Профиль под гипсокартон позволяет быстро соорудить каркас любой конфигурации с применением минимального набора инструментов. Если вы планируете в процессе ремонта использовать гипсокартон, вам следует знать, что металлические изделия для каркаса отличаются размерами, назначением и областью применения. Для того чтобы понять, какой профиль лучше выбрать в том или ином случае, нужно получить о его разновидностях хотя бы минимальное представление.

Профили для гипсокартона можно разделить на 2 основных вида – перегородочные и потолочные. В свою очередь, каждый вид состоит из направляющих (стартовых) и несущих (основных, стоечных) профилей. Направляющие устанавливаются по контуру будущей конструкции, после чего в них вкладывается несущий металлопрофиль. Он образует обрешетку, на которую крепятся ГКЛ. При определенных способах соединения разных деталей получаются различные конструкции: стеновая обшивка, перегородки, короба, ниши, подвесные потолки.

Металлопрофиль делается из стальной ленты с цинковым покрытием толщиной 0,4–0,8 мм на профилегибочных станках, где изделиям придается нужная форма. Тонкий металл (0,4 мм) может применяться только для облицовки стен. Металл большей толщины надежно держит подвесной потолок и используется для создания перегородок.

Любой металлопрофиль имеет спинку и полки, только у направляющего полки прямые, а у несущего – загнутые на концах.

Несущие потолочные профили

Каркас подвесного потолка нагружен только за счет веса конструкции. Потолочный профиль для гипсокартона обозначаемый ПП (CD), составляет основу каркаса и обеспечивает его жесткость.

Металлопрофили CD применяют также для обшивки стен и создания различных конструкций – полок, коробов, ниш, фальшстен, поэтому часто их называют стоечными профилями или стойками, а иногда – плоскостными.

Стоечные профили для гипсокартона имеют ребра жесткости, в которых удобно центрировать саморезы. Края полок загнуты внутрь для большей жесткости и для крепления подвесов.

Стандартный размер позволяет свести к минимуму количество отходов. Длина стойки составляет 2,6 м, 3 м, 4 м. Чаще всего применяют изделия сечением 60 × 27 мм.

Направляющий профиль для потолка

П-образные металлопрофили ПНП (UD) служат для направления и удерживания стоечных элементов.

Латиницей в скобках указывается маркировка Knauf.

Металлопрофиль применяют как при обшивке стен, так и при обустройстве потолка, располагая его по периметру помещения. Направляющие располагаются по периметру каркаса, обеспечивая расположение поверхности листов в одной плоскости. Их длина составляет 3 м, сечение – 28 × 27 мм.

Иногда рекомендуют использовать так называемый эконом профиль с меньшими размерами полок и толщиной и более узкий (направляющие UD 17 × 25, несущие CD 47 × 17) . Его стоимость существенно ниже, но такие изделия можно применять только для потолков при обшивке тонким (0,8–0,95 см) потолочным гипсокартоном и для облицовки стен небольшой площади.

Металлопрофили для перегородок

Стартовый перегородочный профиль ПН (UW) предназначен для монтажа гипсокартонных конструкций. Он крепится на полу и потолке как основа для будущей перегородки. Глубина составляет 40 мм, а ширина – от 50 до 100 мм. Такое разнообразие связано с необходимостью подбора толщины стены.

Стеновой профиль для перегородок из гипсокартона ПС (CW) выполняется с формой поперечного сечения в виде буквы «С». Он также подходит для облицовки стен. Размеры зависят от толщины и высоты конструкции. Длина металлопрофиля подбирается под высоту помещения так, чтобы не было соединений.

Специальные разновидности профиля

Кроме перечисленных разновидностей, существуют специальные изделия, используемые в особых случаях.

Металлопрофиль усиленный UA

Усиленный профиль для гипсокартона применяется с целью повышения прочности конструкции в следующих случаях:

• создание подвесного потолка, имеющего повышенный вес;
• крепление коробок дверей и окон;
• когда нужно усилить высокие конструкции;
• отделка стен с размещением большого количества коммуникаций.

Толщина металла составляет 2 мм, а высота полки – 40 мм.

U- образный металлопрофиль с отбортовками

Профиль применяется для экономии пространства между листом и основанием. Крепление производится через борта к потолкам и стенам. Высота изделия составляет всего 15 мм. Такой металлопрофиль должен стоять на ровном основании.

Профиль арочный ПА (CD)

Применяется для возведения сооружений сложной формы, где имеются изгибы. Изделия имеют те же параметры, что и потолочный металлопрофиль, но на них нанесены фигурные надрезы и перфорация. Арочный профиль можно сделать самостоятельно, для этого разрезают полки потолочного изделия на сектора и сгибают, придавая ему криволинейную форму.

Профиль угловой ПУ

Перфорированный уголок малой толщины (0,22–0,25 мм) служит для повышения прочности внешних углов гипсокартонных конструкций. Применяют оцинкованный и алюминиевый профиль. Угловой профиль монтируется на шпаклевку и ею закрывается.

Виниловые профили

Гибкий профиль для гипсокартона из винила предназначен для отделки углов, соединений конструкции с оконными и дверными блоками или в случае, когда стена имеет сложную форму. Выпускается несколько видов виниловых профилей.

1. Арочный. Применяется для создания криволинейных конструкций с минимальным радиусом изгиба 50 см.
2. J-профиль. Его надевают на кромки гипсокартона. На виниле хорошо удерживается краска.
3. Кабельный. В него вкладывается провод для защиты от шпаклевки.
4. Пазовый – для разделения длинных конструкций из гипсокартона.
5. Уголок перфорированный. Применяется в основном для отделки внутренних углов, придает им четкость и завершенность.

Монтаж направляющего металлопрофиля

Сложности в монтаже металлопрофиля нет, но крепить его нужно по правилам. Способы можно увидеть на многочисленных фото и видео.

От правильности фиксации направляющего профиля для гипсокартона зависит ровность и надежность остальной конструкции. Последовательность монтажа направляющих при обшивке стен следующая:

1. По разметке на пол устанавливается ПН. От его одной части делается отступ на 0,3 м и сверлится отверстие. Еще два отверстия делаются посередине и с другой стороны, после чего профиль крепится дюбель-гвоздями.
2. Последующие направляющие устанавливаются аналогично по периметру потолка и стен.
3. Вся конструкция крепится дюбелями с шагом в 30 см. Перед окончательным монтажом проверяется ровность и точность установки.

Монтаж стоечных профилей

Последовательность монтажа на стену будет следующей:

• Стойки устанавливаются с шагом по размерам листов. На стене отмеряется расстояние по ширине листа и делается метка. Здесь будет проходить осевая линия вертикальной стойки, которая станет местом стыка ГКЛ. Такие метки делаются до конца стены, затем отмечаются центральные точки полученных отрезков. Здесь также будут крепиться стойки, приходящиеся на цент листа. С помощью отвеса проводятся вертикальные линии.
• На полученных линиях через каждые 60 см ставятся метки и в этих местах сверлятся отверстия, после чего в них вставляются дюбели и крепятся подвесы.
• Несущий металлопрофиль устанавливается в направляющие. Все профили выставляются по горизонтально натянутой леске, а заем фиксируются с помощью подвесов, концы которых загибаются и крепятся саморезами. К направляющим стойки крепятся саморезами «клопами» или просекателем.

• Для повышения прочности конструкции к стойкам крепятся горизонтальные перемычки из того же типа металлопрофиля. Сколько их устанавливать, зависит от требуемой прочности каркаса. Они должны также приходиться на места стыков листов.

Листы вместе со своими половинками располагаются в шахматном порядке. Горизонтальные швы соседних листов не должны совпадать.

Заключение

Для создания надежного каркаса под гипсокартон необходимо разбираться в параметрах конструктивных элементов. Гипсокартонная конструкция получается более надежной, если каждый профиль применять по назначению и не заменять его тем, что есть в наличии.

Качество изделий зависит от производителя. Популярность завоевал профиль для гипсокартона Кнауф. Хорошо себя зарекомендовали отечественные профили для гипсокартона, цена которых ниже импортных.

Profilelist — FHIR v4.0.1

This page is part of the FHIR Specification (v4.0.1: R4 — Mixed Normative and STU). This is the current published version. For a full list of available versions, see the Directory of published versions

This specification is a common platform standard that must be adapted to particular use cases. Some particular use cases are common or important enough to be described as a part of the specification itself.These are published as groups of Structure Definitions (profiles or extensions), which are often found in implementation guides, along with Value Sets, newly defined search parameters and examples that are all defined with a common purpose. Additional profiles and extensions may be registered on the HL7 FHIR registry at http://registry.fhir.org

Name	Description	Kind	FMM
General
EHRS FM Record Lifecycle Event — Audit Event	Defines the elements to be supported within the AuditEvent resource in order to conform with the Electronic Health Record System Functional Model Record Lifecycle Event standard	profiles
Clinical Reasoning Extensions	Defines common extensions used by the Clinical Reasoning Module.	extensions
Common extensions for Coding data type	Defines «common» extensions for use with the DataElement data type	extensions
Common extensions for ContactPoint data type	Defines «common» extensions for use with the ContactPoint data type	extensions
Element-definition Extensions for use by FHIR Implementers	A set of extensions that constrain data elements, whether used in DataElements, StructureDefinitions or Questionnaires	extensions
ISO 11179 Element Definition Profile	A profile showing how to use ElementDefinition to express 11179 Data_Element and Concept_Elements.At present, the profile is a partially-complete place-holder	extensions
DataElement constraint on ElementDefinition data type	Identifies how the ElementDefinition data type is used when it appears within a data element	profiles
Common extensions for ElementDefinition data type	Defines «common» extensions for use with the DataElement data type	extensions
Event Pattern HL7 Extensions	This profile defines extensions that can be used to provide alignment with the Event workflow pattern data elements for concepts that may be generally applicable but may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource.See the workflow module for more discussion about this specification that are typically involved in workflow.	extensions
General Extensions for use by FHIR Implementers	A set of general extensions defined for the convenience of implementers that use FHIR resources	extensions
Common extensions for HumanName data type	Defines «common» extensions for use with the HumanName data type	extensions
Common extensions for Identifier data type	Defines «common» extensions for use with the Identifier data type	extensions
ISO 21090 Data Type Extensions	Extra ISO 21090 features not included in data types because of core design policy	extensions
International Realm Pharmacy Extensions Profile	Contains a number of pharmacy domain extensions relevant to a number of medication-related resources.
EHRS FM Record Lifecycle Event — Provenance	Defines the elements to be supported within the Provenance resource in order to conform with the Electronic Health Record System Functional Model Record Lifecycle Event standard	profiles
Common extensions for Quantity data type	Defines «common» extensions for use with the DataElement data type	extensions
Extensions for rendering data elements	A set of extensions dealing with controlling how particular data elements are rendered when displayed.Initially created for questionnaires, but potentially useable elsewhere.	extensions
Request Pattern HL7 Extensions	This profile defines extensions that can be used to provide alignment with the Event workflow pattern data elements for concepts that may be generally applicable but may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource.See the workflow module for more discussion about this specification that are typically involved in workflow.	extensions
Smart App Launch Capability Statements	Formal definitions of Smart App Launch extensions in the CapabilityStatement	extensions
Common extensions for Timing data type	Defines «common» extensions for use with the Timing data type	extensions
Metadata HL7 Extensions	Defines common extensions used with or related to conformance and knowledge resources	extensions
Workflow Pattern HL7 Extensions	This profile defines extensions that can be used to provide alignment with the Event and Request workflow pattern data elements for concepts that may be generally applicable but may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource.See the workflow module for more discussion about this specification that are typically involved in workflow.	extensions
ActivityDefinition
Shareable ActivityDefinition	Enforces the minimum information set for the activity definition metadata required by HL7 and other organizations that share and publish activity definitions	profiles
AllergyIntolerance
openEHR Archetype Profile	A set of extensions that define how the parts of the openEHR RiskOfAdverseReaction archetype that are not generaly encountered by implementers are represented	extensions
AllergyIntolerance HL7 Extensions	Defines common extensions used with or related to the AllergyIntolerance resource	extensions
AuditEvent
AuditEvent HL7 Extensions	Defines common extensions used with or related to the AuditEvent resource	extensions
Bundle
Common extensions for bundle-related types	Defines «common» extensions for use with the Bundle resource and contained elements	extensions
CapabilityStatement
Common CapabilityStatement extensions	Common extensions for use with the CapabilityStatement resource	extensions
CarePlan
Common Care Plan Extensions	A set of commonly used extensions that do not make the usage requirements for inclusion in the resource itself	extensions
CodeSystem
CodeSystem HL7 Extensions	Defines common extensions used with or related to the CodeSystem resource	extensions, search parameters
Shareable CodeSystem	Enforces the minimum information set for the value set metadata required by HL7 and other organizations that share and publish value sets	profiles
Communication
Communication HL7 Extensions	Defines common extensions used with or related to the Communication resource	extensions
CommunicationRequest
CommunicationRequest HL7 Extensions	Defines common extensions used with or related to the CommunicationRequest resource	extensions
Composition
Clinical Document	The Clinical Document profile constrains Composition to specify a clinical document (matching CDA).The base Composition is a general resource for compositions or documents about any kind of subject that might be encountered in healthcare including such things as guidelines, medicines, etc. A clinical document is focused on documents related to the provision of care process, where the subject is a patient, a group of patients, or a closely related concept. A clinical document has additional requirements around confidentiality that do not apply in the same way to other kinds of documents.	profiles, extensions
Profile for Catalog	describes how the Composition resource is used to represent a Catalog	profiles, extensions
Composition HL7 Extensions	Defines common extensions used with or related to the Composition resource	extensions
ConceptMap
ConceptMap HL7 Extensions	Defines common extensions used with or related to the ConceptMap resource	extensions
Condition
Condition HL7 Extensions	Defines common extensions used with or related to the Condition resource	extensions
Consent
Consent HL7 Extensions	Defines common extensions used with or related to the Consent resource	extensions
Device
Device HL7 Extensions	Defines common extensions used with or related to the Device resource	extensions, search parameters
DeviceRequest
DeviceRequest HL7 Extensions	Defines common extensions used with or related to the DeviceRequest resource	extensions
DeviceUseStatement
DeviceUseStatement HL7 Extensions	Defines common extensions used with or related to the DeviceUseStatement resource
DiagnosticReport
Example Lipid Profile	Describes how the lab report is used for a standard Lipid Profile — Cholesterol, Triglyceride and Cholesterol fractions.Uses LOINC codes	profiles	1
DiagnosticReport HL7 Extensions	Defines common extensions used with or related to the DiagnosticReport resource	extensions
DiagnosticReport-Genetics	Describes how the DiagnosticReport resource is used to report structured genetic test results	profiles, extensions, search parameters
Profile for HLA Genotyping Results	Describes how the HLA genotyping results	profiles, extensions
Encounter
Encounter HL7 Extensions	Defines common extensions used with or related to the Encounter resource	extensions
Evidence
Evidence Synthesis Profile	Explanation of what this profile contains / is for.	profiles
EvidenceVariable
PICO Element Profile	Explanation of what this profile contains / is for.	profiles
FamilyMemberHistory
Family member history for genetics analysis	Adds additional information to a family member history supporting both the capture of mother / father relationships as well as additional observations necessary to enable genetics-based risk analysis for patients	profiles, extensions
Family Member History HL7 Extensions	Defines common extensions used with or related to the FamilyMemberHistory resource	extensions
Flag
Flag HL7 Extensions	Defines common extensions used with or related to the Flag resource	extensions
Goal
FHIR Core Goal Profile	This profile holds core Goal extensions	extensions
Group
Group Definition	Enforces a descriptive group that can be used in definitional resources	profiles
Actual Group	Enforces an actual group, rather than a definitional group	profiles
GuidanceResponse
CDS Hooks GuidanceResponse	Defines a GuidanceResponse that represents the response container for a CDS Hooks response	profiles
Immunization
Immunization HL7 Extensions	Defines common extensions used with or related to the Immunization resource
ImmunizationRecommendation
ImmunizationRecommendation HL7 Extensions	Defines common extensions used with or related to the ImmunizationRecommendation resource
ImplementationGuide
FHIR Core ImplementationGuide Profile	This profile holds core ImplementationGuide extensions
Library
Shareable Library	Enforces the minimum information set for the library metadata required by HL7 and other organizations that share and publish libraries	profiles
CQL Library	Represents a CQL logic library	profiles
List
List HL7 Extensions	Defines common extensions used with or related to the List resource	extensions
Location
Location HL7 Extensions	Defines common extensions used with or related to the Location resource	extensions
Measure
Shareable Measure	Enforces the minimum information set for the measure metadata required by HL7 and other organizations that share and publish measures	profiles
Medication
Medication HL7 Extensions	Defines common extensions used with or related to the Medication resource
MedicationAdministration
MedicationAdministration HL7 Extensions	Defines common extensions used with or related to the MedicationAdministration resource
MedicationDispense
MedicationDispense HL7 Extensions	Defines common extensions used with or related to the MedicationDispense resource
MedicationRequest
MedicationRequest HL7 Extensions	Defines common extensions used with or related to the MedicationRequest resource
MedicationStatement
MedicationStatement HL7 Extensions	Defines common extensions used with or related to the MedicationStatement resource
MessageHeader
Common extensions for message header	Defines «common» extensions for use with the messageheader resource and contained elements	extensions
NutritionOrder
NutritionOrder HL7 Extensions	Defines common extensions used with or related to the NutritionOrder resource	extensions
Observation
Device Metric Observation Profile	This profile describes the direct or derived, qualitative or quantitative physiological measurement, setting, or calculation data produced by a medical device or a device component.	profiles
Observation HL7 Extensions	Defines common extensions used with or related to the Observation resource	extensions
Observation-genetics	Describes how the observation resource is used to report structured genetic test results	profiles, extensions, search parameters
observation-vitalsigns	Defines constraints and extensions on the Observation resource for use in querying and retrieving Vital Signs information.	profiles
observation-bodyweight	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign body weight.	profiles
observation-vitalspanel	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital signs panel.	profiles
observation-bodyheight	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign body height.	profiles
observation-resprate	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign respiratory rate.	profiles
observation-heartrate	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign heart rate.	profiles
observation-bodytemp	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign body temperature.	profiles
observation-headcircum	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign head circumference.	profiles
observation-oxygensat	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign oxygen saturation.	profiles
observation-bmi	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign body mass index.	profiles
observation-bp	Defines constraints and extensions on the Observation resource for use in querying and retrieving the vital sign blood pressure.	profiles
OperationDefinition
Standard Operation Definition Extensions	This profile describes common extensions that are used with Operation Definitions	extensions
OperationOutcome
Standard OperationOutcome Extensions	This profile describes common extensions that are used with OperationOutcomes	extensions
Organization
Organization HL7 Extensions	Defines common extensions used with or related to the Organization resource	extensions
OrganizationAffiliation
OrganizationAffiliation HL7 Extensions	Defines common extensions used with or related to the OrganizationAffiliation resource	extensions
Patient
Patient HL7 Extensions	Defines common extensions used with or related to the Patient resource	extensions, search parameters
PlanDefinition
Shareable PlanDefinition	Enforces the minimum information set for the plan definition metadata required by HL7 and other organizations that share and publish plan definitions	profiles
Computable PlanDefinition	Defines a computable PlanDefinition that specifies a single library and requires all expressions referenced from the PlanDefinition to be definitions in that single library	profiles
CDS Hooks Service PlanDefinition	Defines a PlanDefinition that implements the behavior for a CDS Hooks service	profiles
Practitioner
Practitioner HL7 Extensions	Defines common extensions used with or related to the Practitioner resource	extensions
PractitionerRole
PractitionerRole HL7 Extensions	Defines common extensions used with or related to the PractitionerRole resource	extensions
Procedure
Procedure HL7 Extensions	Defines common extensions used with or related to the Procedure resource	extensions
Provenance
Provenance Relevant History	Guidance on using Provenance for related history elements	profiles
Questionnaire
Core extensions for Questionnaire	Contains standard extensions for Questionnaire, amongst others for validation	extensions
CQF-Questionnaire	Adds the ability to define behavior as part of a questionnaire.	profiles
QuestionnaireResponse
Core extensions for QuestionnaireResponse	Contains standard extensions for QuestionnaireResponse, amongst others for validation	extensions, search parameters
RequestGroup
CDS Hooks RequestGroup	Defines a RequestGroup that can represent a CDS Hooks response	profiles
SearchParameter
Standard Search Parameter Extensions	This profile describes common extensions that are used with Search Parameters
ServiceRequest
ServiceRequest-Genetics	Describes how the ServiceRequest resource is used to for genetics	profiles, extensions
Service Request HL7 Extensions	Defines common extensions used with or related to the Service Request resource	extensions
Specimen
Specimen HL7 Extensions	Defines common extensions used with or related to the Specimen resource	extensions
StructureDefinition
Standard Structure Definition Extensions	This profile describes common extensions that are used with Structure Definitions	extensions
Task
Task HL7 Extensions	Defines common extensions used with or related to the Task resource	extensions
ValueSet
ValueSet HL7 Extensions	Defines common extensions used with or related to the ValueSet resource	extensions, search parameters
Shareable ValueSet	Enforces the minimum information set for the value set metadata required by HL7 and other organizations that share and publish value sets	profiles

.

References — FHIR v4.0.1

This page is part of the FHIR Specification (v4.0.1: R4 — Mixed Normative and STU). This is the current published version. For a full list of available versions, see the Directory of published versions

2.3.0 Resource References

This page has been approved as part of an ANSI standard. See the Infrastructure Package for further details.

Many of the defined elements in a resource are references to other resources. Using these references, the resources combine to build a web of information about healthcare.

References are always defined and represented in one direction — from one resource (source) to another (target). The corresponding reverse relationship from the target to the source exists in a logical sense, but is not typically represented explicitly in the target resource.For external references, navigating these reverse relationships requires some external infrastructure to track the relationship between resources (the REST API provides one such infrastructure by providing the ability to search the reverse relationship by naming search parameters for the references and by providing support for reverse includes).

Because resources are processed independently, relationships are not considered to be transitive. For example, if a Procedure resource references a Patient as its subject, and has a Procedure resource as its reason, there is no automatic rule or implication that the condition has the same patient for its subject.Instead, the subject of the condition must be established directly in the Condition resource itself. Another way to state this is that the context of the subject is not «inherited», nor does it «conduct» along the relationship to condition. The only exception to this is the case of contained resources (see below). Note that in practice, the relationships need to describe a logical and coherent record, and in the case of the Condition and Procedure described here, they would usually be required to have the same patient for their subjects.Profiles and / or implementation guides may make rules about this (also see GraphDefinition).

This specification describes the use of references to other resources that have the same FHIR version as the source of the reference. Expected behavior for references across FHIR versions is presently undefined.

References are made to resource based on their identity; there are several different identities to refer to.

Resources contain two types of references to other resources:

• Resource references — general references between resources
• Canonical references — references to resources by their canonical URL (see below)

For canonical references, see below.The general references are handled by the Reference type. which contains at least one of a reference (literal reference), an identifier (logical reference), and a display (text description of target). In addition, it may contain a target type .

UML Diagram (Legend)

ElementExtensions — as described for all elements: additional information that is not part of the basic definition of the resource / typeextension: Extension 0.. * ReferenceA reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with ‘#’) refer to contained resourcesreference: string [0..1] The expected type of the target of the reference.If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent. The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. «Patient» is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources) type: uri [0..1] «Aa resource (or, for logical models, the URI of the logical model). (Strength = Extensible) ResourceType + »An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location . There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the referenceidentifier: Identifier [0..1] Plain text narrative that identifies the resource in addition to the resource referencedisplay: string [0..1]

UML Diagram (Legend)

ElementExtensions — as described for all elements: additional information that is not part of the basic definition of the resource / typeextension: Extension 0 .. * ReferenceA reference to a location at which the other resource is found.The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with ‘#’) refer to contained resourcesreference: string [0..1] The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent. The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. «Patient» is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources) type: uri [0..1] «Aa resource (or, for logical models, the URI of the logical model).(Strength = Extensible) ResourceType + »An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location . There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the referenceidentifier: Identifier [0..1] Plain text narrative that identifies the resource in addition to the resource referencedisplay: string [0..1]

Constraints

At least one of reference , identifier and display SHALL be present (unless an extension is provided).

id	Level	Location	Description	Expression
ref-1	Rule	(base)	SHALL have a contained resource if a local reference is provided	reference.startsWith ( ‘#’). not () or (reference.substring (1) .trace ( ‘url’) in% rootResource.contained.id.trace ( ‘ids’))

2.3.0.1 Target Type

In resources, a Reference always point to another resource, which has a fixed and known type. If appropriate, this type can be specified in the reference itself. In principle, the type of the target reference can be determined by resolving the reference (using the approaches described below), and examining the content returned to determine the type; for this reason, specifying the type is almost always duplication of information.However, resolving references may be a very slow operation, or impossible in practice due to various practical concerns. For this reason, the reference may indicate directly the target resource type:

 "Subject": {
   "Reference": "http: // someserver / some-path",
   "Type": "Patient"
 }
 

When the type is provided directly, it SHALL agree with the type determined by resolving the resource.

Note that in practice, it is often not necessary to know the type of the target resource is, unless it’s going to be resolved anyway, so in many cases, specifying the type of the target resource is unnecessary.

In order to support Logical Models, the type element has the type of «uri». Whenever type appears in resources, the uri is represented relative to the base URI http://hl7.org/fhir/StructureDefinition/ . For resources, then, the value is simply a code that is the type of resource — e.g. «Patient».

2.3.0.2 Literal References

The reference is the key element — resources are identified and addressed by their URL.It contains a URL that is either

• an absolute URL
• a relative URL, which is relative to the Service Base URL, or, if processing a resource from a bundle, which is relative to the base URL implied by the Bundle.entry.fullUrl (see Resolving References in Bundles)
• an internal fragment reference (see «Contained Resources» below)

Notes:

• Using absolute URLs provides a stable, scalable approach suitable for a cloud / web context, while using relative / logical references provides a flexible approach suitable for use when trading across closed ecosystem boundaries.(See «Managing Resource Identity» for further discussion)
• Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. Whether or not the reference is to a FHIR RESTful server, the reference SHALL point to a Resource as defined by this specification.
  Note that This regex is true if the reference to a resource is consistent with a FHIR API:

     ((Http | https): \ / \ / ([A-Za-z0-9 \ - \\\. \: \% \ $] * \ /) +)? (Account | ActivityDefinition | AdverseEvent | AllergyIntolerance | Appointment | AppointmentResponse | AuditEvent | Basic | Binary | BiologicallyDerivedProduct | BodyStructure | Bundle | CapabilityStatement | CarePlan | CareTeam | CatalogEntry | ChargeItem | ChargeItemDefinition | Claim | ClaimResponse | ClinicalImpression | CodeSystem | Communication | CommunicationRequest | CompartmentDefinition | Composition | ConceptMap | Condition | Consent | Contract | Coverage | CoverageEligibilityRequest | CoverageEligibilityResponse | DetectedIssue | Device | DeviceDefinition | DeviceMetric | DeviceRequest | DeviceUseStatement | DiagnosticReport | DocumentManifest | DocumentReference | EffectEvidenceSynthesis | Encounter | Endpoint | EnrollmentRequest | EnrollmentResponse | EpisodeOfCare | EventDefinition | Evidence | EvidenceVariable | ExampleScenario | ExplanationOfBenefit | FamilyMemberHistory | Flag | Goal | GraphDefinition | Group | GuidanceResponse | HealthcareService | ImagingStudy | Immunization | ImmunizationEvaluation | ImmunizationRecommendation | Implementat ionGuide | InsurancePlan | Invoice | Library | Linkage | List | Location | Measure | MeasureReport | Media | Medication | MedicationAdministration | MedicationDispense | MedicationKnowledge | MedicationRequest | MedicationStatement | MedicinalProduct | MedicinalProductAuthorization | MedicinalProductContraindication | MedicinalProductIndication | MedicinalProductIngredient | MedicinalProductInteraction | MedicinalProductManufactured | MedicinalProductPackaged | MedicinalProductPharmaceutical | MedicinalProductUndesirableEffect | MessageDefinition | MessageHeader | MolecularSequence | NamingSystem | NutritionOrder | Observation | ObservationDefinition | OperationDefinition | OperationOutcome | Organization | OrganizationAffiliation | Patient | PaymentNotice | PaymentReconciliation | Person | PlanDefinition | Practitioner | PractitionerRole | Procedure | Provenance | Questionnaire | QuestionnaireResponse | RelatedPerson | RequestGroup | ResearchDefinition | ResearchElementDefinition | ResearchStudy | ResearchSubject | RiskAssessment | RiskEvidenceSynthesis | Schedule | SearchParameter | ServiceRequest | Slot | Specimen | SpecimenDefinition | StructureDefinition | StructureMap | Subscription | Substance | SubstanceNucleicAcid | SubstancePolymer | SubstanceProtein | SubstanceReferenceInformation | SubstanceSourceMaterial | SubstanceSpecification | SupplyDelivery | SupplyRequest | Task | TerminologyCapabilities | TestReport | TestScript | ValueSet | VerificationResult | VisionPrescription) \ / [A- Za-z0-9 \ - \.] {1,64} (\ / _ history \ / [A-Za-z0-9 \ - \.] {1,64})?
      

  
  However, conformance with this regex is no guarantee that the end-point is a FHIR server
• URLs are always considered to be case-sensitive
• The URL may contain a reference to a canonical URL (see below) and applications can use the canonical URL resolution methods they support when resolving references, though the | [version] syntax part of the canonical reference is not supported
• References SHALL be a reference to an actual FHIR resource, and SHALL be resolvable (given that access control works, there is no temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL (see below) and looking it up in a local registry / repository

A relative reference to the Patient «034AB16» in an element named subject on a FHIR RESTful server:

An absolute reference to a Structure Definition in an element named profile :

{
  "Profile": {
    "Reference": "http: // fhir.hl7.org/svc/StructureDefinition/c8973a22-2b5b-4e76-9c66-00639c99e61b "
  }
}
 

Note that in a bundle during a transaction, reference URLs may actually contain logical URIs (e.g. OIDs or UUIDSs) that resolve within the transaction. When processing the transaction, the server replaces the logical URL with what is the correct literal URL at the completion of the transaction.

References can be version specific — that is, a reference may point to a specific version of a resource.e.g .:

This is usually associated with audit trail or provenance information where it is important to reference a specific version of a record, not the most current information.

2.3.0.3 Logical References

In many contexts where FHIR is used, applications building a resource may know an identifier for the target of the reference, but there is no way for the application to convert this to a literal reference that directly references an actual resource.This situation may arise for several reasons:

• There is no server exposing any such resource. This is often the case with national identifiers (e.g. US SSN or NPI), and such identifiers are widely used
• The server that exposes the resource is not available to the source application, so it has no way to resolve an identifier to a reference
• The application is not in a RESTful environment — it is creating a message or a document

For further discussion of the use of identifiers on resources, see Consistent Resource Identification.In these cases, the source application may provide the identifier as a logical reference to the entity that the target resource would describe.

A logical reference to the Patient with an SSN of 000111111:

There is no requirement that a Reference.identifier point to something that is actually exposed or exists as a FHIR instance (except, of course, that the reference will need to be resolved to a target resource if any information from it is required in a FHIR context). The reference SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference (Observation | DiagnosticReport).One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (Where the type is Reference (Any).

When processing a resource, an application may be able to use the identifier directly, on the grounds that all it needs is the identifier, or it may be able to resolve the identifier directly. Alternatively, it may be able to use a server to resolve the logical reference to a literal reference to a resource.

Irrespective of how the resolution occurs, any system processing a logical reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) ​​but often it is not.

For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able to automatically resolve the reference.Servers may accept an identifier based reference untouched, resolve it, and / or reject it — see CapabilityStatement.rest.resource.referencePolicy.

When both logical and literal references are provided, the literal reference is preferred. Applications processing the resource are allowed — but not required — to check that the identifier matches the literal reference, if they understand how to resolve the logical reference.

Applications converting a logical reference to a literal reference may choose to leave the logical reference present; or may remove it.

2.3.0.4 Reference Description

Irrespective of whether a literal and / or logical reference is provided, or neither, the display element may be used to provide a very short description of the target resource.

This text can be used by any application that can not resolve the reference to fill out the text portion of a hyperlink referring to the target resource, for instance.It can also save time fetching a target resource and determining how to convert it to a very short textual description.

In general, the display , if populated, does not have identical content to the Resource.text of the referenced resource. The purpose is to identify what’s being referenced, not to more fully describe it.

2.3.0.5 Canonical URLs

Many resource types have a defined element «url» which is the canonical URL that always identifies the resource across all contexts of use.Typically, terminology, conformance or knowledge resources have canonical URLs. The canonical URL is the preferred way to reference a resource instance for the resource types on which it is defined. See Canonical Resource Identity for further information.

References to canonical URLs use the canonical type to refer to the url element on the conformance / knowledge resources (which has the type uri):

References of type canonical may include a version, in order be precise about which version of the resource is being referred to. To do this, append the version to the reference with a ‘|’ like this:

This is a version specific reference to a value set. Note that this refers to the ValueSet.version not the ValueSet.meta.versionId . Searching for this on a FHIR server would look like this:

GET fhir / ValueSet? Url = http: //hl7.org/fhir/ValueSet/my-valueset&version=0.8
 

Note that if a References to a canonical URL does not have a version, and the server finds multiple versions for the value set, the system using the reference should pick the latest version of the target resource and use that. Servers SHOULD support version specific searching for canonical URLs by automatically detecting the presence of a | [version] and performing the appropriate search.Additional notes about searching on versioned references to canonical URLs:

• Search only regards the latest version for each different logical id
• If there is no match (either because .version is empty or is different), the instance will not be matched, and will not appear in the result bundle
• This search only works for specific data elements of type of uri that act as canonical URL’s (see list below)

Systems resolving references to canonical URLs SHOULD first try to resolve the reference using the canonical reference (e.g. search on a known registry of terminology, conformance, or knowledge resources as appropriate), and then fall back to direct resolution using the URL as a literal reference if a local version of the canonical resource can not be found. This approach is safe because the approaches must refer to the same artifact, though implementations will need to make appropriate arrangements regarding the version and / or currency of their local copy of the artifact.

The following resources have canonical URLs and are allowed to be the target of a references to a canonical URLs:

A few elements that have references to canonical URLs have a targetProfile of http: // hl7.org / fhir / StructureDefinition / Resource , which is shown as canonical (Any) in this specification. Such references SHALL only reference one of these types of resources.

2.3.0.6 Canonical Reference and Fragments

Canonical references may include a fragment when the reference is to a contained resource. When the target of a canonical reference is a contained resource, the canonical reference will have a fragment as part of the URL:

This is a reference to the value set with id «vs1» in version 1.0 of the identified questionnaire. The common case for this is internal references:

Which is the form for references to the contained value set inside the above example questionnaire.

2.3.0.7 Rendering References in Resource Narratives

References between resources create a challenge when rendering resource narratives: the narrative includes information from the target resources.As an example, consider an Observation with a patient reference:

{
  "ResourceType": "Observation",
  "Subject": {
    "Reference": "Patient / example"
  }
}
 

When represented in XHTML, this reference will generally become something like:

  ...
 Patient:  Peter James CHALMERS (12345)   ...
 

This implies that the system generating the resource narrative will need to resolve the reference and generate a summary, or that the reference will contain the information (generated by an application that is able to resolve the reference):

{
  "ResourceType": "Observation",
  "Subject": {
    "Reference": "Patient / example",
    "Display": "Peter James CHALMERS (12345)"
  }
}
 

Narrative that contains information derived from other resources like this is still regarded as ‘generated’ (for Narrative.status).

It’s not mandatory to generate narrative this way. Narrative may be generated like this:

  ...
 Patient:  (link)   ...
 

However, users generally prefer a more informative narrative, so this is not always acceptable.

Applications (and networks of applications) will need some kind of systematic approach for resolving references and / or maintaining the currency of narratives as the resources they reference are changed.The exact details of this are out of scope for the FHIR standard.

Applications are encouraged to use the Reference.display element to store a user presentable representation of the resource for when the resource can not be resolved (e.g. due to network errors). The canonical type does not have a display element because applications are generally expected to carry cached copies of the resources that are the target of the canonical references.If this functionality is still needed or desired anyway, the Rendered Value extension can be used.

2.3.0.8 Contained Resources

In some circumstances, the content referred to in the resource reference does not have an independent existence apart from the resource that contains it — it can not be identified independently, and nor can it have its own independent transaction scope. Typically, such circumstances arise where resources are being assembled by a secondary user of the source data, such as a middleware engine.If the data available when the resource is constructed does not include record keys or absolute identification information, then a properly identified resource can not be assembled, and even if an arbitrary identification was associated with it, the resource could never be the subject of a transaction outside the context of the resource that refers to it.

For example, consider a situation where an interface engine is creating a Condition record on a patient from an HL7 v2 message, and the only information about the primary surgeon is her first name and last name (REL-7.2 & REL-7.3). In the absence of a controlled practitioner directory, this is not enough information to create an identified Practitioner resource since more than one practitioner might have the same name.

In these circumstances, the resource is placed directly in-line in the resource. This SHOULD NOT be done when the content can be identified properly, as once the identification is lost, it is extremely difficult (And context dependent) to restore it again. The FHIR version of a contained resource SHALL always be the same as the resource that contains it.

An example of a contained resource:

The same example in JSON:

{
  "ResourceType": "Condition",
  "Contained": [
    {
      "ResourceType": "Practitioner",
      "Id": "p1",
      "Name": [{
        "Family": "Person",
        "Given": [ "Patricia"]
      }]
}],
   "Asserter": {
     "Reference": "# p1"
  }
}
 

Implementation Note: Contained resources are still a reference rather than being inlined directly into the element that is the reference (e.g. «Custodian» above) to ensure that a single approach to resolving resource references can be used. Though direct containment would seem simpler, it would still be necessary to support internal references where the same contained resource is referenced more than once. In the end, all that it would achieve is creating additional options in the syntax. For users using XPath to process the resource, the following XPath fragment resolves the internal reference:

ancestor :: f: * [not (parent :: f: *)] / f: contained / * [@ id = substring-after ( current ()  / f: reference / @ value, '#')]
 

Some notes about use and interpretation of contained resources:

• The contained element SHALL NOT have extensions on it (though contained resources can still contain extensions).
• The contained resource can be put in any resource that inherits from DomainResource. The contained element is then located at the beginning of the resource after any text narrative and before any extension.
• Contained resources share the same internal id resolution space as the parent resource (for id attributes, see Narrative references).
• When resolving references, references are resolved by looking through the ‘container’ resource — the one that contains the other resources.Since there are no nested contained resources, there is only one container resource.
• References to contained resources are never resolved outside the container resource. Specifically, resolution stops at the elements Bundle.entry.resource and Parameters.parameter.resource, but not at DomainResource.contained.
• Both Reference and canonical types may refer to contained resources
• Contained resources SHALL NOT contain additional contained resources.
• Contained resources SHALL NOT contain meta.versionId , meta.lastUpdated , or meta.security .
• Contained resources MAY contain meta.tag , though there are many tags that do not make sense on contained resources.
• A contained resource SHALL only be included in a resource if something in that resource (potentially another contained resource) has a reference to it.

Like other resources, contained resources can contain narrative.However, when rendering the containing resource, the narrative of the contained resources is ignored, so relevant information about contained resources SHALL appear in the narrative of the containing resource.

Resources that are contained inline do not «inherit» context from their parent resource. For instance, if the parent resource contains a «subject», and the contained resource also has a «subject» element defined, there is no implication that the contained resource has the same subject as the parent resource.

Resources can only be contained in other resources if there is a reference from the resource to the contained resource, or if the contained resource references the container resource. This is intended to ensure that the meaning of the contained resource is clear, and that there is no confusion as to its significance.

For a resource that references the container, the reference is «#», like this:

There is no way to search for contained resources that reference their container.Is this a problem?

Feedback is welcome here.

2.3.0.9 Circular Resource References

Some references are circular — that is, the reference points to another resource of the same type. There are several reasons why a resource may refer to other resources of the same type:

• part-of: the resources describe a complex hierarchy composed of parts e.g. an organization structure
• builds-on: resources may add additional content to another resource by deriving from it e.g. extending type declarations
• replaces: one resource may be replaced by another due to changes over time e.g. replacing a prescription or to support patient merging
• uses / re-uses: a resource may use another resource in a modular arrangement e.g. library references or value sets including other value sets

For parameters where the relationship is a strict hierarchy (i.e. where it would be wrong to have circular references, even transitively), there is additional search support for traversing the hierarchy using: above and: below modifiers on the search parameters.

Hierarchical references with search parameters (can have: above and: below modifiers on search parameters):

References that may refer back to the source instance:

References for which the hierarchical behavior is not specified:

.

Terminologies — FHIR v4.0.1

This page is part of the FHIR Specification (v4.0.1: R4 — Mixed Normative and STU). This is the current published version. For a full list of available versions, see the Directory of published versions

This page has been approved as part of an ANSI standard. See the Infrastructure Package for further details.

Many elements in the FHIR resources have a coded value : some fixed string (A sequence of characters) assigned elsewhere that identifies some defined «concept».The sequence of characters and its meaning may be defined in one of several places:

• As one of a set of fixed values ​​defined in this specification
• In an internet RFC (e.g. mime type, language)
• An HL7 specification (HL7 v3 code system, or HL7 v2 table)
• Some external terminology or ontology such as LOINC, or SNOMED CT
• A locally maintained dictionary, look up table or enumeration in an application (for further discussion of locally defined value sets, see «Profiling FHIR»

These methods of defining codes are collectively called «code systems».This list is far from complete; there are many ways to define code systems, and they vary widely in sophistication and size.

Throughout this specification, coded values ​​are always treated as a pair composed of «system» and «code», where the system is a URL that identifies the code system that defines the codes. Note that system values ​​are always case sensitive. Different code systems make their own rules as to whether the codes they define are case sensitive or not.Note that all the codes defined by FHIR itself are case sensitive and SHALL be used in the provided case (usually, but not always, lowercase).

The FHIR framework for using coded values ​​is based on the fundamental framework defined in section 5 of the HL7 v3 Core Principles document, including the separation between code systems and value sets.

The general pattern for representing coded elements is using the following four elements:

system	A URI that identifies the system (see below)
version	Identifies the version of the system (see Code System Versioning)
code	A string pattern that identifies a concept as defined by the code system
display	A description of the concept as defined by the code system

The Coding data type represents this pattern.This example shows a LOINC code with the LOINC system, the version of LOINC used for the definition, and the display assigned by LOINC:

{
  "System": "http://loinc.org",
  "Version": "2.62",
  "Code": "55423-8",
  "Display": "Number of steps in unspecified time Pedometer"
}
 

When codes are carried in resources, one of several different data types is used:
code	The instance represents the code only.The system is implicit — it is defined as part of the definition of the element, and not carried in the instance.
Coding	A data type that has a code and a system element that identifies where the definition of the code comes from
CodeableConcept	A type that represents a concept by plain text and / or one or more coding elements (See the datatype notes for a discussion of code translations and using text in CodeableConcept)
In addition, the following data types also carry coded values, or content that can be treated as a code and bound to a valueset:
Quantity	The instance has system and code elements for carrying a code for the type of unit, and these can be bound to a value set
string	The instance carries a string.In some cases, applications may wish to control the set of valid strings for a particular element, so the string value can be treated as a coded element (like code )
uri	Like string , URIs can be treated as a coded element

Notes:

4.1.1 Coded Values, Code Systems, and Value Sets

The set of coded values ​​that is allowed in an element is known as a «value set».Anywhere these data types are used, the specification «binds» a value set to the element, and for the types code, Coding, and CodeableConcept, always does.

• Code Systems define concepts and give them meaning through formal definitions, and assign codes that represent the concepts
• Value Sets specifies a set of codes defined by code systems that can be used in a specific context

The difference between a code system and a value set is an important distinction that is easily missed by implementers, since the difference is often overlooked in system design.For instance, it’s not unusual to see an application table that is a mixed list of codes, containing some LOINC codes and also some additional in-house codes. Quite often, there is no explicit differentiation between them; only the fact that a code happens to look like a LOINC code betrays its origin.

For data exchange, on the other hand, explicitly tracking the source of the code is both important and necessary. In order to do this, each code system that defines codes is assigned a URL that identifies it, and all the codes it defines are actually a pair ( «Code Pair»: a name with a namespace).So in the case of this mixed list example from the previous paragraph, there are two code systems: LOINC (http://loinc.org) and a local one (let’s say it has been given the URL: http://example.com/codesystems/additional-test-codes). The application table is a single value set (a set of Code Pairs) that includes codes from each of those two namespaces. The value set itself is given its own URL as an identifier (e.g. «http://example.com/fhir/ValueSet/test-codes»). This identifies the set of Code Pairs, but is never used as the namespace in an actual code pair, or in an instance.In FHIR, Code Pairs are always represented as «code» and «system», except for the simple data type code where the namespace (e.g. the system element / property) is fixed in the schema and not represented explicitly.

Note that for some code systems, there is a single correct mechanism by which to represent codes defined by the system as a single URL. These single URLs are used in the context of the RDF format to enable ontological reasoning. The URL is often a direct reference to a web source that can provide additional definitional material about the concept.Where the mechanism is known, and defined by the code system, it is described in this specification.

4.1.2 Choosing a system

The URL in a system is always a reference to a code system, not to a value set. The system ensures that codes can be unambiguously traced back to their original definition, and that logical comparisons, matching and inferences can be performed consistently by different systems. For this reason, choice of the correct URI for the system attribute is critical.

The correct value to use in the system for a given code system can be determined by working through the following list, in order:

• The specification Code System Registry — if a code system is listed here, it SHALL be used
• A system URI or OID defined as the correct value to use in FHIR by the publisher of the code system
• The FHIR community code system registry — if a code system is listed here with status = active, it SHALL be used
• An OID registered in the HL7 OID registry — if a code system is registered here, the OID SHOULD be used (using the syntax urn: oid: [oid])

If a code system is not resolved by this list, and there is no publisher to consult, implementers must choose a URI to use.The priority should be to choose a unique value that will not accidentally be used by another implementer for a different purpose — or a very similar purpose with a different scope. See Registering Code Systems for further advice.

For publishers of code systems, the following considerations should be kept in mind when defining the correct URI to use:

• Once defined, the URI will require agreement from all implementers to change, and some might not be able to change (stored resources).If the set of users is not closed, it will usually not be possible to change the URI
• Implementers strongly prefer a human readable URI. http://acme.com/patients/mrn is a great deal easier to work with than urn: oid: 1.2.3.4.5.6.7
• An http: address SHOULD resolve to some useful description of the code system. Ideally, if a user makes a request of the address with the media type set to a FHIR media type, the server will respond with a CodeSystem resource, but some other human or computable definition is allowed
• HTTP addresses should be permalinks which may re-direct to the current correct content
• A scope of the code system URI and the correct usage of codes and displays in its namespace SHOULD be clearly defined.See examples for SNOMED CT, RxNorm, LOINC, NDC
• Generally, allocation of URLs is hierarchical, and most care is required in choosing the Base URL. Once sub-URL policies are clearly defined, URIs can often be automatically assigned

Note: if the code system is made available packaged inside a ValueSet resource, the correct URL for the system value is ValueSet.codeSystem.system , not ValueSet.uri .

4.1.3 Complex Code Systems

All code systems define a set of concepts, assign specific codes to them, and provide definitional material to guide implementers in the correct use and understanding of the codes. Many code systems define relationships between the different concepts — is-a, part-of, classifies-with, and many other relationships. These features are represented in the CodeSystem resource, and exchanged using one of the code data types described above.

Some code systems define rules for how complex expressions can be built using the basic concepts defined by the code system. This is sometimes referred to as «Post-coordination». Some of the more notable code systems that define grammars for expressions are:

There are many others. Any expression defined by the code system is still regarded as a ‘code’ and represented as such.

This example shows a SNOMED CT expression:

{
  "System": "http: // snomed.info / sct ",
  "Code": "128045006: {363698007 = 56459004}"
}
 

Note that there is no display defined for SNOMED CT expressions.

4.1.4 Controlling the use of Coded Values ​​

When an element is bound to a value set, the binding has these properties:

Name	A descriptive name used when presenting information about the binding
Strength	How the binding should be understood — see below
Reference	A URL that defines the value set.Usually, this is a direct reference to a ValueSet resource, but can be a more indirect reference, where the value set is inferred
Description	A text description of the use of the codes. If there is no reference, this must be populated. When there is a reference, this can be used to make additional notes about the use and implementation of the value set

A binding is always represented using an ElementDefinition.binding.

4.1.4.1 Value Set References

There are a number of places in the specification where value sets are referenced in order to bind a coded value to a value set:

ElementDefinition.binding.valueSet	Used to bind a defined element to a value set
ConceptMap.source [x] and .target [x]	Used to indicate the scope of the mapping in the Concept Map — from one value set to another
Questionnaire.item.answerValueSet	Indicates that answers to a set of questions come from a value set
ValueSet.compose.include.valueSet	The content of a value set includes the content in the imported value set too
OperationDefinition.parameter.binding.valueSet	Used to bind a defined parameter to a value set
ValueSet Reference Extension	Indicates that a coded value was chosen from the specified value set

When referencing value sets, the reference is usually made to the definition of a value set — that is, a value set that defines what codes are in the value set.A terminology server is required to convert this definition to the actual expansion that specifies what codes are in the value set in the context of operation.

There are two types of value set references in this list, direct and logical.

4.1.4.1.1 Direct Value Set references

A direct value set reference has the type Reference, and refers directly to a ValueSet based on a URL, usually to a terminology server running a FHIR RESTful API.When accessing a value set based on this kind of reference, a system should access the URL directly (after converting a relative reference to an absolute reference according to the local context). If this process fails, the system is unable to resolve the value set and must handle the error appropriately.

Example:

GET fhir / Questionnaire / 234


  ...
  
    
      
    
  
  ....

 

This specifies that the values ​​for a questionnaire come from the ValueSet with id 234234 on the same FHIR end-point. To resolve this, the system would GET fhir / ValueSet / 234234

Typically, a direct reference like this is good for in-process references, in closed or carefully managed eco-systems. In a more general context, these references tend to be fragile over time because web URLs — including RESTful API URLS — are easily reassigned.For this reason, systems are encouraged to use logical value set references.

4.1.4.1.2 Logical Value Set references

A logical value set reference has the type uri, where an absolute URI is provided that matches the one in ValueSet.url. The value set URL can — and is preferred to be — a web address that resolves directly to a fixed web address that serves as the authoritative source for that value set. Alternatively, the system can query its terminology server (s) to resolve a value set with that URL as its identity.

Example:

  ...
  
    ...
    
      ...
      
    
    ...
  
  ....

 

This specifies that the element is bound to the value set with a ValueSet.url of http://hl7.org/fhir/ValueSet/clinical-findings.One way to access this value set is to try GET http://hl7.org/fhir/ValueSet/clinical-findings — which works, for this value set — http://hl7.org/fhir/ValueSet/clinical-findings returns the authoritative value set for this URL.

Alternatively, the value set could be resolved using a local terminology server. If that’s running a FHIR Terminology Server, then this would work like this:

GET fhir / ValueSet? Url = http: //hl7.org/fhir/ValueSet/clinical-findings
 

if the terminology server knows the value set, then it will return the value set.If the URL does not resolve to an authoritative value set, and the terminology server (s) do not know the value set, the system is unable to resolve the value set and must handle the error appropriately.

The value set URL is allowed to be a URI such as a UUID (e.g. urn: uuid: c0e0d027-1250-4278-8f44-33a49dc67916). These value sets can never be accessed directly, and must come from a terminology server. Note that this specification defines many value sets that have a logical URL that is not resolvable (Examples for SNOMED CT, RxNorm, LOINC)

Using a logical reference which is a direct reference to the authoritative value set is the easiest and most reliable approach.However, this requires suitable hosting arrangements, and can not always be guaranteed, so it is not required.

Version specific Logical References

A value set has a two-part identifier: a url, and a version. Some value sets only ever have a single ‘version’; a revision of the value set contents will cause a new url to be assigned. Others, however, maintain the same URL, and change the version. A terminology server may have multiple value sets for the same ValueSet.url with different versions.

To be precise about which version of a value set is being referred to in a value set reference, append the version to the canonical URL with a ‘|’ like this:

This is a version specific reference to a value set. Searching for this on a terminology server would look like this:

GET fhir / ValueSet? Url = http: // hl7.org / fhir / ValueSet / clinical-findings & version = 0.8
 

Note that if a value set reference does not have a version, and the server finds multiple versions for the value set, the system using the value set should pick the latest version of the value set and use that. Note that this applies to all conformance resources.

4.1.4.1.3 Unbound

Note that as a matter of ongoing development, a few elements that have coded data types are not bound to any value set at all.Bindings are to be provided for these elements.

4.1.5 Binding Strengths

Almost all the elements that have a coded data type are bound to a value set. The bindings are associated with various degrees of flexibility as to how closely the value set should be followed:

required	To be conformant, the concept in this element SHALL be from the specified value set.
extensible	To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated.If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
preferred	Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
example	Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.

The precise conformance criteria for ‘required’ and ‘extensible’ binding strengths vary by the data type to which they are applied, as described in the paragraphs below.

Irrespective of the binding strength, when a StructureDefinition is used to describe local usage, it can bind the element to a different value set in order to be much more precise about exactly which coded values ​​can be used for these elements, and / or increase the strength of the binding.There are different rules for this, depending on the binding strength, as discussed below. Generally it is expected that jurisdictions, projects and vendors will work together to choose actual working value sets.

4.1.5.1 Required

To be conformant, codes in this element SHALL be from the specified value set.

In the standard, this is generally used for elements where the value needs to be strictly controlled so that everyone can interpret it with confidence.Generally, this is used for elements with type code:

• the element is bound to a value set that contains a list of distinct codes with a specified system (and version, where required)
• the element is bound to some external standard that defines the set of valid codes that can be used (typical examples are Mime Types, Language Codes, UCUM, etc.)

The other place where this is used is when profiling resources, and there is agreement within a context of use that a specified set of codes are the only ones that can be used.In these cases, the data type SHALL contain one of the values ​​in the value set.

The following rules apply when required bindings are used with the CodeableConcept data type:

• at least one Coding element SHALL be present
• one of the Coding values ​​SHALL be from the specified value set
• text can be provided as well, and is always recommended, but is not an acceptable substitute for the required code

If a required binding is applied to an element with maximum cardinality> 1, the binding applies to all the elements.

The following rules apply when required bindings are used with the code data type:

• Where the value set is defined by FHIR, the list of allowed codes will be fixed in the XML schema
• Comparison between codes is always case sensitive unless the codes are selected by reference (e.g. ValueSet.compose), and the referenced specification clearly states otherwise
• The list of codes that can be used can only be extended in subsequent releases of the FHIR specification

When an element is bound to a required value set, derived profiles may state rules on which codes can be used, including removing codes from allowed use, but can not specify new or additional codes for these elements.

4.1.5.2 Extensible

To be conformant, codes in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated.

Note that it is the value set binding that is extensible, not the value set itself.

If there is no applicable concept in value set (based on human review), an alternate concept (either system / code pair, or text ) may be used instead.The alternate concept can have any level of specificity in an is-a hierarchy (See Condition instance # 2).

If there is at least one applicable concept in the extensibly-bound value set with a meaning which includes but is more general than the meaning that is intended to be represented by the element in the resource instance, then the code that is used in the instance SHALL be taken from the value set and should be the closest available match for the intended element instance meaning (i.e. neither more general or more specific). However, a more specific code that more completely represents the intended meaning may also be included in the instance as an additional Coding if the data type is CodeableConcept, but it can not be used instead of the code from the value set. This helps ensure that systems know which codes they should expect to receive and build logic for and it facilitates interoperability.

When a code for an applicable concept in the extensibly-bound value set is used it should always be the closest available match for the intended element instance meaning, regardless of hierarchical (i.e. «Is-a») relationships in the underlying code system (s) or hierarchical «level» of the concept. However, as noted above, a code for a concept that is outside of the extensibly-bound value set with a meaning which is «covered by» (i.e. is more specific than or has an «is-a» relationship to) a concept that is included in the value set can not be used. In that case a code for a concept that is in the extensibly-bound value set SHALL be used in the element instance and it should be the code for the concept that most closely matches the intended element instance meaning.

If the data type is CodeableConcept, then, as noted above, one of the Coding values SHALL be from the specified extensibly-bound value set if a code in that value set applies, but if no applicable code exists in the value set alternate code (s) from outside the value set may be used instead. If no codes, including local codes, are available, then text alone (in CodeableConcept.text) may be used.

If the data type is Coding, then the code / system SHALL be from the specified value set if a code applies, but if no suitable code exists in the value set, an alternate code may be provided in its place.

If an extensible binding is applied to an element with maximum cardinality> 1, the binding applies to all the elements.

Identified gaps in value sets should be submitted to the organization administering the value set in order to improve interoperability in the future.

Extensible bindings are used when there is consensus at the specification or profiling level about the coded values that should be used, but it is impossible to create a bounded list of codes that are known to cover all use cases, including ones that are yet to arise.

When an element is extensibly-bound to a value set, derived profiles may state rules on which codes can be used, but can not select new or additional codes for these elements unless no codes with appropriate meanings are found in the base value set.

Note that if the valueset-reference extension is being used and the code in the element instance is from outside the extensibly-bound value set, the extension must reference a different value set that the code was chosen from (or if no other value set reference is available the extension can not be used in that instance).

4.1.5.2.1 Examples for Extensible Bindings

See examples to help explain the difficult but important subject of Extensible bindings.

4.1.5.3 Preferred

Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.

If the data type is CodeableConcept, then one of the Coding values ​​SHOULD be from the specified value set, but another code and / or text can be used in its place.

Preferred bindings are used when there is consensus at the specification level about the coded values that are the best to be used, but there is recognition that some implementation contexts are unable to use the recommended codes for a variety of reasons. Applications should consider adopting the preferred value set wherever possible, as these preferred value sets are the most likely to serve interoperability purposes in the future.

When an element is bound to a preferred value set, derived profiles may bind the element to any value set they choose.

4.1.5.3.1 Examples for Preferred Bindings

See examples of how Preferred bindings work.

4.1.5.3.2 Example Bindings

Instances are not expected or even encouraged to draw from the specified value set.The value set merely provides examples of the types of concepts intended to be included.

Example bindings are used when an element has a very broad meaning (such as List.code), or there is no consensus over the correct codes to be used. For these bindings:

• Coding : the system / code values ​​MAY be one of the codes in the value set.
• CodeableConcept : one of the coding elements MAY contain a system / code that is in the value set.

Some other coded value MAY be used, or (for a CodeableConcept), a text alternative MAY be provided. Example value sets are provided to assist implementers to understand the correct use of an element. Value sets based on code systems such as SNOMED CT that have restrictive license terms will only be used as example bindings in the base FHIR specification, though implementation guides for particular jurisdictions may adopt value sets that require licenses.In addition, well-specified realm-specific ValueSets may also be used as example bindings in the base specification.

When an element is bound to an example value set, derived profiles may bind the element to any value set they choose.

4.1.6 Other notes

• Subsequent versions of FHIR may replace example value sets with preferred bindings if enough consensus emerges in the relevant sphere.
• Bindings to value sets provided as part of the specification are always specific to the version of the value set published with the specification.The value set may be sealed by defining a simple list of enumerated codes, or it may include codes by their properties, along with a non-version specific reference to an underlying code system, in which case the list of valid concepts may change over time.

4.1.6.1 Binding String Values ​​

In a few special cases, humans customarily use codes directly for elements that have type «string». A typical case is codes for states, and there are several places where a URI must come from a set of controlled values.An element of type string or uri can also be bound to a value set. When a string or URI is bound to a value set, the value property SHALL contain the code specified by the value set, and the system and display values ​​are ignored.

4.1.6.2 Terminology Service

FHIR has defined a Terminology Service specification which sets requirements for systems that support the use of codes, value sets and code systems.

.

Extensibility-examples — FHIR v4.0.1

This page is part of the FHIR Specification (v4.0.1: R4 — Mixed Normative and STU). This is the current published version. For a full list of available versions, see the Directory of published versions

2.5.2 Extensibility Examples

In order to use an extension, there is a three-step process:

1. Define the extension
2. Register the extension
3. Use it in the instance

This page contains examples of how this process executes.

2.5.2.1 Patient Consent for Record Sharing

The basic patient resource contains no information relating to patient consent, and / or the policy under which the patient consents to their registration details. A social web provider of personal healthcare record (PHR) services might be obliged to keep track of the particular policy under which a patient has created their relationship with the PHR provider, and share this with their participants via their FHIR API.If they wish, they can extend the patient resource to represent the patient’s participation agreement. Note that other approaches to this problem are possible and preferred, but this example suffices to demonstrate the extension process.

For the purposes of this example, we assume that the patient agrees to a participation policy as part of their sign up, and that as the provider has to change their policy, they ask patients to agree to new participation details.Each participation agreement has a URI by which it is identified, and the patient resource will carry this URI for each policy agreement that the patient has agreed to.

2.5.2.1.1 Define the Extension

For each extension, the first thing to do is to fill out the definitional properties of the extension:

Code	«participation-agreement»
Context	This extension is used in the patient resource
Short Defn	Agreed agreement / policy
Definition	A URI that identifies a participation agreement / policy to which the patient has agreed
Comment	URI is a literal reference to agreement text (html)
Cardinality	1.. * (Patient can not participate without at least one agreement)
Type	uri
Invariants	No invariants
is Modifier	No (the participation agreements do not affect that interpretation of the elements of the patient, though they will likely influence how the system interacts with the patient)
Binding	(no binding — not a coded value)

2.5.2.1.2 Write the Definition of the Extension

From this table, we can build a formal extension definition. In this case, it looks like this:

Note that usually one would build the actual profile using a tool.This example was built by hand for this example.

2.5.2.1.3 Register the Extension

This means the profile shown above that defines the extension is placed on the web somewhere. By preference, it will be hosted at a FHIR Profile endpoint, and the best location of all is the HL7 FHIR Registry.

For this example, we assume that it has been uploaded to the PHR provider’s own website at http://example.org/phr/documents/fhir/extensions.

2.5.2.1.4 Use it in the instance

To use the extension in an instance, the extension is placed in the root of the resource, because that was the declared context for the extension. Note that the URL of the extension refers to the registered location.

2.5.2.1.5 Using it in a Patient Profile

The extension definition above simply defines the extension «participation-agreement» and says that it is used with patient. But the profile above does not say that the server actually uses it. For the PHR provider to indicate that all Patient resources will use this resource, a StructureDefinition on the patient resource is used:

Note — this step is optional.

2.5.2.2 Patient Name Parts

ISO 21090 (Healthcare Data Types) defines a concept called a «name part qualifier» that contains extra information about how a particular name part should be used or interpreted.In practice, this field is used rarely except in particular cultural contexts, where certain part qualifiers are used as a matter of practice. Following the FHIR design policy, such a field is not included in the overall definition of the core name data type, instead is it added as an extension.

In practice, for cases such as these in ISO 21090, HL7 defines common extensions, and these are defined either in this specification, or in the FHIR registry.

2.5.2.2.1 Define the Extension

For each extension, the first thing to do is to fill out the definitional properties of the extension:

Code	«name-qualifier»
Context	This extension can be used anywhere a HumanName.part appears
Short Defn	(one of the codes) LS | AC | NB | PR | HON | BR | AD | SP | MID | CL | IN
Definition	A set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type
Comment	Used to indicate additional information about the name part and how it should be used
Cardinality	0.. * (This is always optional, but more than one can be used if required)
Type	code
Invariants	N / A
Is Modifier	No (Qualifiers do not change the fact that the part is a given or family name)
RIM Mapping	ENXP.qualifier
v2 Mapping	N / A
Binding	Bound to a subset of the codes specified for EntityNamePartQualifierR2 in ISO 21090

Not all the codes of the EntityNamePartQualifierR2 are required in this context, because prefix and suffix are explicitly part of the name types.Rather than simply refer to the OID for EntityNamePartQualifierR2 (2.16.840.1.113883.5.1122), in this case we enumerate the available codes, and set the type of the extension to code. The type of «code» is only allowed if the profile itself defines the codes that can be used. Here is a table of the codes (see the EntityNamePartQualifierR2 reference for the full definitions):

LS	Legal status	For organizations, a suffix…
AC	Academic	Indicates that a prefix like «D …
NB	Nobility	In Europe and Asia, there are s …
PR	Professional	Primarily in the British Im …
HON	Honorific	An honorific such as ‘The Rig …
BR	Birth	A name that a person was given at…
AD	Acquired	A name part a person acquired. …
SP	Spouse	The name assumed from the partner …
MID	Middle Name	Indicates that the name par …
CL	Call me	Call me is used to indicate which …
IN	Initial	Indicates that a name part is ju…

This is all then represented formally in a profile. Such profiles do not need to include resource constraint statements; instead, they include just extension declarations and their associated bindings. In this case, the definition looks like this: