FHIR:Vissue-MM-4101 FHIR Profiling Guidelines R4 - Bewerkingsoverzicht

Luud Slagter: MM-4101: Corrected several typos

2022-12-07T05:55:24Z

MM-4101: Corrected several typos

← Oudere versie		Versie van 7 dec 2022 05:55
Regel 485:		Regel 485:
	Functional models for measurements will usually be mapped onto the FHIR Observation resource. The type of measurement is conveyed using {{fhir\|Observation.code}} and the result of the measurement is conveyed using {{fhir\|Observation.value[x]}}, or {{fhir\|Observation.component.value[x]}} if the measurement consists of multiple components.		Functional models for measurements will usually be mapped onto the FHIR Observation resource. The type of measurement is conveyed using {{fhir\|Observation.code}} and the result of the measurement is conveyed using {{fhir\|Observation.value[x]}}, or {{fhir\|Observation.component.value[x]}} if the measurement consists of multiple components.

	However, sometimes the functional model requires that the type of measurement needs to be further specified using a qualifier. For this purpose, the {{fhir\|Observation.method}} and {{fhir\|~~Observaton~~.bodySite}} elements can be used. If it is not possible to map these concepts to these elements or to a core extension of Observation, they may be mapped to {{fhir\|Observation.component}}, according to a remark in the specification ([https://www.hl7.org/fhir/r4/observation.html#gr-comp "or may provide qualifying information to {{fhir\|Observation.code}}"]) and [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pathology.20Lab.20Reports.20.E2.80.93.20Dynamic.20Function.20Tests.20.2F.20Timed.20Tests/near/227279594 a discussion on Zulip], which concludes that the use of {{fhir\|~~Observatoin~~.component}} for qualifiers is appropriate and preferred above (custom) extensions.		However, sometimes the functional model requires that the type of measurement needs to be further specified using a qualifier. For this purpose, the {{fhir\|Observation.method}} and {{fhir\|Observation.bodySite}} elements can be used. If it is not possible to map these concepts to these elements or to a core extension of Observation, they may be mapped to {{fhir\|Observation.component}}, according to a remark in the specification ([https://www.hl7.org/fhir/r4/observation.html#gr-comp "or may provide qualifying information to {{fhir\|Observation.code}}"]) and [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pathology.20Lab.20Reports.20.E2.80.93.20Dynamic.20Function.20Tests.20.2F.20Timed.20Tests/near/227279594 a discussion on Zulip], which concludes that the use of {{fhir\|Observation.component}} for qualifiers is appropriate and preferred above (custom) extensions.

	===HL7 Vital Signs===		===HL7 Vital Signs===
Regel 499:		Regel 499:
	* O2Saturation		* O2Saturation

	The FHIR spec defines derived profiles for each of these vital signs, plus [https://www.hl7.org/fhir/observation-vitalsigns.html an IG] with further ~~recommandations~~.		The FHIR spec defines derived profiles for each of these vital signs, plus [https://www.hl7.org/fhir/observation-vitalsigns.html an IG] with further recommendations.

	However, the HL7 Vital Signs profile imposes two issues that make it impossible to implement zib profiles for the relevant vital signs measurements directly onto it:		However, the HL7 Vital Signs profile imposes two issues that make it impossible to implement zib profiles for the relevant vital signs measurements directly onto it:

Luud Slagter: MM-4101: Corrected contact information metadata (2)

2022-12-07T05:50:35Z

MM-4101: Corrected contact information metadata (2)

← Oudere versie		Versie van 7 dec 2022 05:50
Regel 463:		Regel 463:
	** name: <q>Nictiz</q>		** name: <q>Nictiz</q>
	** telecom:		** telecom:
	*** system: <q>~~email~~</q>		*** system: <q>url</q>
	*** value: <q><nowiki>~~info@~~nictiz.nl</nowiki></q>		*** value: <q><nowiki>https://www.nictiz.nl</nowiki></q>
	*** use: <q>work</q>		*** use: <q>work</q>
	* description: <q>Maps [functional ValueSet] codes as found in [linked description to the functional model] to [FHIR ValueSet] codes as found in FHIR R4.</q><p>For zibs, the linked description will be <q>the Dutch [zib ('Zorginformatiebouwsteen', i.e. Health and Care Information Model) ''[English zib name]'' ''[version]''(''[release]'')](''[link to the English zib page on zibs.nl]'').</q>		* description: <q>Maps [functional ValueSet] codes as found in [linked description to the functional model] to [FHIR ValueSet] codes as found in FHIR R4.</q><p>For zibs, the linked description will be <q>the Dutch [zib ('Zorginformatiebouwsteen', i.e. Health and Care Information Model) ''[English zib name]'' ''[version]''(''[release]'')](''[link to the English zib page on zibs.nl]'').</q>

Luud Slagter: MM-4101: Corrected contact information metadata

2022-12-07T05:49:47Z

MM-4101: Corrected contact information metadata

← Oudere versie		Versie van 7 dec 2022 05:49
Regel 419:		Regel 419:
	** name: <q>Nictiz</q>		** name: <q>Nictiz</q>
	** telecom:		** telecom:
	*** system: <q>~~email~~</q>		*** system: <q>url</q>
	*** value: <q><nowiki>~~info@~~nictiz.nl</nowiki></q>		*** value: <q><nowiki>https://www.nictiz.nl</nowiki></q>
	*** use: <q>work</q>		*** use: <q>work</q>
	* description:		* description:

Luud Slagter: MM-4101: Corrected several typos

2022-12-07T05:48:19Z

MM-4101: Corrected several typos

Luud Slagter: Clone of V1.0 production page for issue MM-4101

2022-12-07T05:43:13Z

Clone of V1.0 production page for issue MM-4101

Wijzigingen bekijken

← Oudere versie		Versie van 7 dec 2022 05:48
Regel 67:		Regel 67:
	Concepts in a functional description oftentimes refer to each other; e.g. most clinical concepts will refer to the concept of a Patient. In FHIR these connections are realized using the reference datatype, which allow to specify the target (base resource of profile) as well. For example, a profile representing the zib Problem could set the target of the {{fhir\|.subject}} element to the profile representing the zib Patient.		Concepts in a functional description oftentimes refer to each other; e.g. most clinical concepts will refer to the concept of a Patient. In FHIR these connections are realized using the reference datatype, which allow to specify the target (base resource of profile) as well. For example, a profile representing the zib Problem could set the target of the {{fhir\|.subject}} element to the profile representing the zib Patient.

	However, setting the target explicitly means a restriction of the allowed targets, which runs counter to the principles of open world ~~modelling~~. On the other hand, specifying a dedicated profile provides useful guidance on how to handle this profile. To address both concerns, the target profile will be added next to the base resource.For example, the Condition resource allows Patient and Group as target in the {{fhir\|.subject}} element. When profiling the zib Problem, the profile representing the zib Patient will be added as a third option.		However, setting the target explicitly means a restriction of the allowed targets, which runs counter to the principles of open world modeling. On the other hand, specifying a dedicated profile provides useful guidance on how to handle this profile. To address both concerns, the target profile will be added next to the base resource. For example, the Condition resource allows Patient and Group as target in the {{fhir\|.subject}} element. When profiling the zib Problem, the profile representing the zib Patient will be added as a third option.

	=Functional model as base=		=Functional model as base=
Regel 73:		Regel 73:
	Most, if not all, conformance resources are based on an underlying functional model. The functional model is the specification to which the conformance resources should adhere.		Most, if not all, conformance resources are based on an underlying functional model. The functional model is the specification to which the conformance resources should adhere.

	The basis for most other functional models is formed by the [https://zibs.nl/wiki/HCIM_Mainpage 'zibs' ('Zorginformatiebouwstenen')], in English also known as are Clinical Information Models (CIMs), Health and Care Information Models (HCIMs) or Clinical Building Blocks (CBB) -- we will use the Dutch term 'zib' for all profiling work as it has become a recognizable term over the past years. The zibs are defined by the program ‘Registratie aan de bron’ (Data capture at the point of care) and provide a foundation of use case neutral building blocks from which use cases can be built. The formal definition of the zibs can be found on the [https://zibs.nl zibs wiki]		The basis for most other functional models is formed by the [https://zibs.nl/wiki/HCIM_Mainpage 'zibs' ('Zorginformatiebouwstenen')], in English also known as are Clinical Information Models (CIMs), Health and Care Information Models (HCIMs) or Clinical Building Blocks (CBB) -- we will use the Dutch term 'zib' for all profiling work as it has become a recognizable term over the past years. The zibs are defined by the program ‘Registratie aan de bron’ (Data capture at the point of care) and provide a foundation of use case neutral building blocks from which use cases can be built. The formal definition of the zibs can be found on the [https://zibs.nl zibs wiki].

	Use cases or information standards use and refine those zibs that are relevant to the situation. The formal specification for these information standards can usually be found in [https://decor.nictiz.nl/art-decor/ Nictiz' instance of ART-DECOR].		Use cases or information standards use and refine those zibs that are relevant to the situation. The formal specification for these information standards can usually be found in [https://decor.nictiz.nl/art-decor/ Nictiz' instance of ART-DECOR].
Regel 201:		Regel 201:
	Slicing can often occur on different levels within an element, e.g. when the element is of type {{datatype\|CodeableConcept}}, a slice can be made on the element itself or on the child element of type {{datatype\|Coding}} ({{fhir\|.''element''.coding}}). In general, slicing will occur on the highest level possible, thus on the element itself in the example above. Note that this is only possible for repeating elements (max cardinality > 1). When an element of type {{datatype\|CodeableConcept}} does not repeat, the {{datatype\|Coding}} element ''can'' be sliced, but this is discouraged as this is often not what is meant; when {{fhir\|.coding}} repeats within a single element of type {{datatype\|CodeableConcept}}, it must have the same semantic meaning although some granularity difference is accepted (eg. when communicating the same concept in different code systems).		Slicing can often occur on different levels within an element, e.g. when the element is of type {{datatype\|CodeableConcept}}, a slice can be made on the element itself or on the child element of type {{datatype\|Coding}} ({{fhir\|.''element''.coding}}). In general, slicing will occur on the highest level possible, thus on the element itself in the example above. Note that this is only possible for repeating elements (max cardinality > 1). When an element of type {{datatype\|CodeableConcept}} does not repeat, the {{datatype\|Coding}} element ''can'' be sliced, but this is discouraged as this is often not what is meant; when {{fhir\|.coding}} repeats within a single element of type {{datatype\|CodeableConcept}}, it must have the same semantic meaning although some granularity difference is accepted (eg. when communicating the same concept in different code systems).

	In general, the slice discriminator is set to {{fhir\|discriminator.type}} = {{term\|value}} and {{fhir\|discriminator.path}} to the path where the discriminator value is located (if it is the root element, it should be noted as <code>$this</code>). The sliced element gets a {{fhir\|pattern}} or a {{term\|required}} ValueSet binding on the location of the path. No further cardinality ~~constrains~~ are added in the sliced element that correspond with the {{fhir\|pattern[x]}} as they are made mandatory by the pattern.		In general, the slice discriminator is set to {{fhir\|discriminator.type}} = {{term\|value}} and {{fhir\|discriminator.path}} to the path where the discriminator value is located (if it is the root element, it should be noted as <code>$this</code>). The sliced element gets a {{fhir\|pattern}} or a {{term\|required}} ValueSet binding on the location of the path. No further cardinality constraints are added in the sliced element that correspond with the {{fhir\|pattern[x]}} as they are made mandatory by the pattern.
	These general slicing guidelines apply to the following situations. See [[FHIR:Vprepub-1.0_FHIR_Profiling_Guidelines_R4_examples\|this page for examples in XML]]:		These general slicing guidelines apply to the following situations. See [[FHIR:Vprepub-1.0_FHIR_Profiling_Guidelines_R4_examples\|this page for examples in XML]]:
	* [[#Mapping_semantic_codes_to_profiles\|Mapping semantic codes to profiles]] requires the presence of the semantic code while leaving the option to use the element for other concepts, e.g the zib ~~LaboratoryTestResultCode~~ profile uses {{fhir\|Observation.category}} for a ~~sematic~~ code that represents the zib ''and'' to map the zib concept ResultType.		* [[#Mapping_semantic_codes_to_profiles\|Mapping semantic codes to profiles]] requires the presence of the semantic code while leaving the option to use the element for other concepts, e.g the zib LaboratoryTestResult profile uses {{fhir\|Observation.category}} for a semantic code that represents the zib ''and'' to map the zib concept ResultType.
	* Identifier systems are always defined on a sliced {{fhir\|.identifier}}, even if there is only one defined.		* Identifier systems are always defined on a sliced {{fhir\|.identifier}}, even if there is only one defined.

Regel 246:		Regel 246:
	** The slice is named after the full English name of the value set according to the functional description, in camelCased notation.		** The slice is named after the full English name of the value set according to the functional description, in camelCased notation.
	** The binding strength is set to {{term\|required}}. This is needed in order to make a valid slice definition.		** The binding strength is set to {{term\|required}}. This is needed in order to make a valid slice definition.
	** The minimum cardinality of the slice is set to 1; if the concept is included, ~~bot~~ the FHIR and function model codes are required.		** The minimum cardinality of the slice is set to 1; if the concept is included, both the FHIR and function model codes are required.
	** The ConceptMap is documented using the permitted-value-conceptmap extension on the ValueSet bound in this slice.		** The ConceptMap is documented using the permitted-value-conceptmap extension on the ValueSet bound in this slice.
	** {{fhir\|binding.description}} is set to: <q>In addition to a coding from this ValueSet, the corresponding coding from the FHIR base ValueSet SHALL be communicated. The ConceptMap <[canonical of ConceptMap]> can be used to relate these two ValueSets.</q>		** {{fhir\|binding.description}} is set to: <q>In addition to a coding from this ValueSet, the corresponding coding from the FHIR base ValueSet SHALL be communicated. The ConceptMap <[canonical of ConceptMap]> can be used to relate these two ValueSets.</q>
Regel 454:		Regel 454:
	** If there is a ConceptMap, {{fhir\|.binding.description}} will be: <q>Use ConceptMap [ConceptMap.name] to translate terminology from the functional model to profile terminology in ValueSet [ValueSet.name]</q>		** If there is a ConceptMap, {{fhir\|.binding.description}} will be: <q>Use ConceptMap [ConceptMap.name] to translate terminology from the functional model to profile terminology in ValueSet [ValueSet.name]</q>
	* For elements that are (directly or indirectly) included in a custom constraint defined elsewhere:		* For elements that are (directly or indirectly) included in a custom constraint defined elsewhere:
	** The keys of all related constraints are added to {{fhir\|.condition}} (note: this is thus not necessary when the constraint is defined on the element itself). Because {{fhir\|.condition}} is added to notify the implementer that a constraint applies to the usage if this element, this rule applies to both the element directly mentioned in the constraint as well as its child element(s) that contain the mapping to the functional model.		** The keys of all related constraints are added to {{fhir\|.condition}} (note: this is thus not necessary when the constraint is defined on the element itself). Because {{fhir\|.condition}} is added to notify the implementer that a constraint applies to the usage of this element, this rule applies to both the element directly mentioned in the constraint as well as its child element(s) that contain the mapping to the functional model.

	===ConceptMaps===		===ConceptMaps===
Regel 567:		Regel 567:
	\| {{datatype\|complex}} \|\| {{datatype\|ANY}} \|\| {{datatype\|BackboneElement}} \|\| {{datatype\|complex}} is data which is not further defined in DECOR, and thus cannot be translated.		\| {{datatype\|complex}} \|\| {{datatype\|ANY}} \|\| {{datatype\|BackboneElement}} \|\| {{datatype\|complex}} is data which is not further defined in DECOR, and thus cannot be translated.
	\|-		\|-
	\| {{datatype\|currency}} \|\| - \|\| {{datatype\|Money}}\|\| Does not have a zib counterpart currently. Theoretically this could be {{datatype\|MO}}		\| {{datatype\|currency}} \|\| - \|\| {{datatype\|Money}}\|\| Does not have a zib counterpart currently. Theoretically this could be {{datatype\|MO}}.
	\|-		\|-
	\| {{datatype\|date}} \|\| - \|\| {{datatype\|date}} \|\| Does not have a zib counterpart currently. Closest counterpart could be {{datatype\|TS}}		\| {{datatype\|date}} \|\| - \|\| {{datatype\|date}} \|\| Does not have a zib counterpart currently. Closest counterpart could be {{datatype\|TS}}.
	\|-		\|-
	\| {{datatype\|datetime}} \|\| {{datatype\|TS}} \|\| {{datatype\|dateTime}} \|\|		\| {{datatype\|datetime}} \|\| {{datatype\|TS}} \|\| {{datatype\|dateTime}} \|\|
	\|-		\|-
	\| {{datatype\|decimal}} \|\| - \|\| {{datatype\|decimal}} \|\| Does not have a zib counterpart currently. ~~Theoratically~~ this could be {{datatype\|REAL}}		\| {{datatype\|decimal}} \|\| - \|\| {{datatype\|decimal}} \|\| Does not have a zib counterpart currently. Theoretically this could be {{datatype\|REAL}}.
	\|-		\|-
	\| {{datatype\|duration}} \|\| - \|\| {{datatype\|Duration}} \|\| Does not have a zib counterpart currently. Closest counterpart could be {{datatype\|PQ}}		\| {{datatype\|duration}} \|\| - \|\| {{datatype\|Duration}} \|\| Does not have a zib counterpart currently. Closest counterpart could be {{datatype\|PQ}}.
	\|-		\|-
	\| {{datatype\|identifier}} \|\| {{datatype\|II}} \|\| {{datatype\|Identifier}} \|\|		\| {{datatype\|identifier}} \|\| {{datatype\|II}} \|\| {{datatype\|Identifier}} \|\|
Regel 583:		Regel 583:
	\| {{datatype\|string}} \|\| {{datatype\|ST}} \|\| {{datatype\|string}} or {{datatype\|markdown}}\|\|		\| {{datatype\|string}} \|\| {{datatype\|ST}} \|\| {{datatype\|string}} or {{datatype\|markdown}}\|\|
	\|-		\|-
	\| {{datatype\|ratio}} \|\| - \|\| {{datatype\|Ratio}} \|\| Does not have a zib counterpart currently. Closest counterpart could be {{datatype\|RTO}}		\| {{datatype\|ratio}} \|\| - \|\| {{datatype\|Ratio}} \|\| Does not have a zib counterpart currently. Closest counterpart could be {{datatype\|RTO}}.
	\|-		\|-
	\| {{datatype\|text}} \|\| - \|\| {{datatype\|string}} \|\| Does not have a zib counterpart currently.		\| {{datatype\|text}} \|\| - \|\| {{datatype\|string}} \|\| Does not have a zib counterpart currently.