FHIR:Vprepub-1.0 FHIR Profiling Guidelines STU3 - Bewerkingsoverzicht

Pieter Edelman: MM-1752: Add guidance on identity of examples and fixtures

2021-03-30T12:43:34Z

MM-1752: Add guidance on identity of examples and fixtures

← Oudere versie		Versie van 30 mrt 2021 12:43
Regel 109:		Regel 109:
	* For profiles: ''<<the final part of the canonical URI>>''.xml		* For profiles: ''<<the final part of the canonical URI>>''.xml
	* For valuesets: ''<<Valueset.name>>''-''<<Valueset.id>>''.xml		* For valuesets: ''<<Valueset.name>>''-''<<Valueset.id>>''.xml

			====Examples and fixtures====
			To ensure ensure consistency of examples and fixtures (example instances used for test/qualification purposes) the {{fhir\|.id}} and file name are standardized in the following way:
			* For fixtures: <code>[profile id]-[3 character project prefix]-[unique string]</code>, capped to 64 characters. The <code>[project prefix]</code> is necessary to prevent the same id from being used by different projects in the same test environment. It is preferably the same as its matching ART-DECOR project prefix.
			* For examples: <code>[profile id]-{[3 character project prefix]-}[unique string]</code>, capped to 64 characters (the <code>[3 character project prefix]</code> is not needed for examples, but may be included to facilitate re-use of tools for both fixtures and examples).

	===Profile meta data===		===Profile meta data===

Pieter Edelman: Create prepub environment from FHIR:V1.0

2021-01-05T13:41:23Z

Create prepub environment from FHIR:V1.0

← Oudere versie		Versie van 5 jan 2021 13:41
Regel 1:		Regel 1:
			__NOINDEX__
	{{DISPLAYTITLE:FHIR Profiling Guidelines}}		{{DISPLAYTITLE:FHIR Profiling Guidelines}}
	==Introduction==		==Introduction==

Pieter Edelman: Gekopieerd van FHIR:V1.0 FHIR Profiling Guidelines STU3, versie 8749

2021-01-05T13:41:22Z

Gekopieerd van FHIR:V1.0 FHIR Profiling Guidelines STU3, versie 8749

← Oudere versie	Versie van 5 jan 2021 13:41
(geen verschil)

Pieter Edelman: Pieter Edelman heeft pagina FHIR:FHIR Profiling Guidelines hernoemd naar FHIR:V1.0 FHIR Profiling Guidelines STU3

2020-12-03T12:07:00Z

Pieter Edelman heeft pagina FHIR:FHIR Profiling Guidelines hernoemd naar FHIR:V1.0 FHIR Profiling Guidelines STU3

← Oudere versie	Versie van 3 dec 2020 12:07
(geen verschil)

Pieter Edelman: Correct title after move to the FHIR namespace

2020-11-05T16:31:07Z

Correct title after move to the FHIR namespace

← Oudere versie		Versie van 5 nov 2020 16:31
Regel 1:		Regel 1:
			{{DISPLAYTITLE:FHIR Profiling Guidelines}}
	==Introduction==		==Introduction==

Pieter Edelman: Pieter Edelman heeft pagina FHIR Profiling Guidelines hernoemd naar FHIR:FHIR Profiling Guidelines: Onboard this page into the FHIR namespace

2020-11-05T16:29:38Z

Pieter Edelman heeft pagina FHIR Profiling Guidelines hernoemd naar FHIR:FHIR Profiling Guidelines: Onboard this page into the FHIR namespace

← Oudere versie	Versie van 5 nov 2020 16:29
(geen verschil)

Pieter Edelman: Fix broken link

2020-09-14T09:18:00Z

Fix broken link

← Oudere versie		Versie van 14 sep 2020 09:18
Regel 224:		Regel 224:
	** The HCIM Dutch concept name is placed in the profile element.alias		** The HCIM Dutch concept name is placed in the profile element.alias
	** {{anchor\|Placing-Info}}''Note: as a rule of thumb, we place this info 'as close as possible' to the elements that actually represent the data. For example: when slicing, the texts are placed on the slice content, not the slice itself. Similarly, in concept containers like Observation.component, this info is placed on the .valueXXX elements. This is also true for [[#Associating_functional_definition_to_StructureDefinition \| the HCIM mappings]].''		** {{anchor\|Placing-Info}}''Note: as a rule of thumb, we place this info 'as close as possible' to the elements that actually represent the data. For example: when slicing, the texts are placed on the slice content, not the slice itself. Similarly, in concept containers like Observation.component, this info is placed on the .valueXXX elements. This is also true for [[#Associating_functional_definition_to_StructureDefinition \| the HCIM mappings]].''
	** Implementation guidance, such as mapping clarification and usage, of HCIM concepts that are mapped to multiple elements is given on the root of the resource. The [http://simplifier.net/resolve?fhirVersion=STU3&scope=nictiz.fhir.nl.stu3.zib2017@2.0.0&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-address provides a good example.		** Implementation guidance, such as mapping clarification and usage, of HCIM concepts that are mapped to multiple elements is given on the root of the resource. The [http://simplifier.net/resolve?fhirVersion=STU3&scope=nictiz.fhir.nl.stu3.zib2017@2.0.0&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-address nl-core-address profile] provides a good example.
	* Slices get an UpperCamelCased name based on the HCIM element name.		* Slices get an UpperCamelCased name based on the HCIM element name.
	* New elements defined through extensions get a lowerCamelCased name based on the HCIM element name.		* New elements defined through extensions get a lowerCamelCased name based on the HCIM element name.

Ardon Toonstra: /* Miscellaneous */ add guideline for implementation guidance for HCIM concepts that are mapped to multiple FHIR elements.

2020-09-14T08:40:57Z

Miscellaneous: add guideline for implementation guidance for HCIM concepts that are mapped to multiple FHIR elements.

← Oudere versie		Versie van 14 sep 2020 08:40
Regel 224:		Regel 224:
	** The HCIM Dutch concept name is placed in the profile element.alias		** The HCIM Dutch concept name is placed in the profile element.alias
	** {{anchor\|Placing-Info}}''Note: as a rule of thumb, we place this info 'as close as possible' to the elements that actually represent the data. For example: when slicing, the texts are placed on the slice content, not the slice itself. Similarly, in concept containers like Observation.component, this info is placed on the .valueXXX elements. This is also true for [[#Associating_functional_definition_to_StructureDefinition \| the HCIM mappings]].''		** {{anchor\|Placing-Info}}''Note: as a rule of thumb, we place this info 'as close as possible' to the elements that actually represent the data. For example: when slicing, the texts are placed on the slice content, not the slice itself. Similarly, in concept containers like Observation.component, this info is placed on the .valueXXX elements. This is also true for [[#Associating_functional_definition_to_StructureDefinition \| the HCIM mappings]].''
			** Implementation guidance, such as mapping clarification and usage, of HCIM concepts that are mapped to multiple elements is given on the root of the resource. The [http://simplifier.net/resolve?fhirVersion=STU3&scope=nictiz.fhir.nl.stu3.zib2017@2.0.0&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-address provides a good example.
	* Slices get an UpperCamelCased name based on the HCIM element name.		* Slices get an UpperCamelCased name based on the HCIM element name.
	* New elements defined through extensions get a lowerCamelCased name based on the HCIM element name.		* New elements defined through extensions get a lowerCamelCased name based on the HCIM element name.

Ardon Toonstra: /* Choosing the discriminator */

2020-07-17T14:10:13Z

Choosing the discriminator

← Oudere versie		Versie van 17 jul 2020 14:10
Regel 162:		Regel 162:
	===Slicing definitions===		===Slicing definitions===
	====Choosing the discriminator====		====Choosing the discriminator====
	Defining the discriminator should be based on the most specific slice definition as possible while keeping a close eye on performance cost. Use patterns instead of a combination of fixed values to keep the discriminator logic simple. For example ~~with~~ slicing the Coding/CodeableCocept datatype: use a pattern slice if the code and system of a slice are fixed. If the slices are discriminated by different CodeSystems then a discriminator based on a fixed system is preferred over a ValueSet binding. Use the latter if multiple CodeSystems can be used within a slice definition. Try to avoid the discriminator type 'profile' as this is a very costly operation for a validator.		Defining the discriminator should be based on the most specific slice definition as possible while keeping a close eye on performance cost. Use patterns instead of a combination of fixed values to keep the discriminator logic simple. For example when slicing the Coding/CodeableCocept datatype: use a pattern slice if the code and system of a slice are fixed. If the slices are discriminated by different CodeSystems then a discriminator based on a fixed system is preferred over a ValueSet binding. Use the latter if multiple CodeSystems can be used within a slice definition. Try to avoid the discriminator type 'profile' as this is a very costly operation for a validator.

	====Don't use nested slicing====		====Don't use nested slicing====

Ardon Toonstra: /* Practical guidelines */ added practical guideline for choosing slicing definition

2020-07-17T13:42:48Z

Practical guidelines: added practical guideline for choosing slicing definition

← Oudere versie		Versie van 17 jul 2020 13:42
Regel 160:		Regel 160:
	\| \|\| \|\| \|\| .display \|\| display value defined in the code system as ''defaultValue'' \|\| 0..1		\| \|\| \|\| \|\| .display \|\| display value defined in the code system as ''defaultValue'' \|\| 0..1
	\|}		\|}
			===Slicing definitions===
			====Choosing the discriminator====
			Defining the discriminator should be based on the most specific slice definition as possible while keeping a close eye on performance cost. Use patterns instead of a combination of fixed values to keep the discriminator logic simple. For example with slicing the Coding/CodeableCocept datatype: use a pattern slice if the code and system of a slice are fixed. If the slices are discriminated by different CodeSystems then a discriminator based on a fixed system is preferred over a ValueSet binding. Use the latter if multiple CodeSystems can be used within a slice definition. Try to avoid the discriminator type 'profile' as this is a very costly operation for a validator.

	====Don't use nested slicing====		====Don't use nested slicing====
	In some cases, slicing in this way would mean to add slices within slices (e.a. Observation.component). This doesn't work too well in FHIR - for example, neither the Java nor the .Net validator can't handle this (at the moment) - so we don't use this mechanism. As an alternative we can use a slicing ~~disciminator~~ based on pattern/code, and on each slice.code we can add a ''patternCodeableConcept'' with the required system and value. This has the same effect; at least that coding is required, but others may be added.		In some cases, slicing in this way would mean to add slices within slices (e.a. Observation.component). This doesn't work too well in FHIR - for example, neither the Java nor the .Net validator can't handle this (at the moment) - so we don't use this mechanism. As an alternative, we can use a slicing discriminator based on pattern/code, and on each slice.code we can add a ''patternCodeableConcept'' with the required system and value. This has the same effect; at least that coding is required, but others may be added.

	===Binding HCIM defined ValueSets===		===Binding HCIM defined ValueSets===
Regel 173:		Regel 176:
	The [https://zibs.nl/wiki/BasicElements-v1.0(2017EN) BasicElements] were made explicit in HCIM Release 2017 and have been declared applicable to [https://zibs.nl/wiki/BasicElements-v1.0(2015EN) 2015] and [https://zibs.nl/wiki/BasicElements-v1.0(2016EN) 2016] in the zibs.nl wiki.		The [https://zibs.nl/wiki/BasicElements-v1.0(2017EN) BasicElements] were made explicit in HCIM Release 2017 and have been declared applicable to [https://zibs.nl/wiki/BasicElements-v1.0(2015EN) 2015] and [https://zibs.nl/wiki/BasicElements-v1.0(2016EN) 2016] in the zibs.nl wiki.

	Initially the profiles did not dedicate much attention to the BsasicElements as there was no clarity around how to interpret them. That clarity has [https://zibs.nl/wiki/BasicElements-v1.0(2017EN)#Concept since been added] but there is still room for interpretation:		Initially, the profiles did not dedicate much attention to the BsasicElements as there was no clarity around how to interpret them. That clarity has [https://zibs.nl/wiki/BasicElements-v1.0(2017EN)#Concept since been added] but there is still room for interpretation:

	{{NoteBox\|All HCIM's implicitly contain a number of basic elements. These are usually not included in the information models of the individual building blocks, but are supposed to be present.		{{NoteBox\|All HCIM's implicitly contain a number of basic elements. These are usually not included in the information models of the individual building blocks but are supposed to be present.
	These are concepts that are of a more technical nature, often have little or no clinical relevance, but are necessary for the sake of clarity and readability of the information. In those cases where these elements are of clinical significance, they will usually be explicit in the information models. An example of this is an AGB number as an identification number for a health professional.}}		These are concepts that are of a more technical nature, often have little or no clinical relevance, but are necessary for the sake of clarity and readability of the information. In those cases where these elements are of clinical significance, they will usually be explicit in the information models. An example of this is an AGB number as an identification number for a health professional.}}