Luud Slagter op 16 jun 2022 om 08:51

2022-06-16T08:51:14Z

Luud Slagter: /* Functional definitions */

2022-06-16T08:39:46Z

Functional definitions

← Oudere versie		Versie van 16 jun 2022 08:39
Regel 16:		Regel 16:
	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 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 were originally defined by the program ‘Registratie aan de bron’ (Data capture at the point of care). This program ended in ~~april~~ 2022 and maintenance and further developement of zibs was transferred to the Nictiz' zib-centrum. Zibs 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 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 were originally defined by the program ‘Registratie aan de bron’ (Data capture at the point of care). This program ended in April 2022 and maintenance and further developement of zibs was transferred to the Nictiz' zib-centrum. Zibs 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 zibs that are relevant to the situation. The formal specification for these information standards (a dataset constrained with cardinalities and conformance applied, comparable to what FHIR calls a ''logical model'') ~~is linked~~ is linked to from the information standard specific IG.		Use cases or information standards use and refine zibs that are relevant to the situation. The formal specification for these information standards (a dataset constrained with cardinalities and conformance applied, comparable to what FHIR calls a ''logical model'') is linked to from the information standard specific IG.

	===Layering: zibs, nl-core profiles and information standard specific profiles===		===Layering: zibs, nl-core profiles and information standard specific profiles===

Jorn Duwel: Version 0.9

2022-06-15T16:05:57Z

Version 0.9

Wijzigingen bekijken

← Oudere versie		Versie van 16 jun 2022 08:51
Regel 18:		Regel 18:
	The basis for most other functional models is formed by the [https://zibs.nl/wiki/HCIM_Mainpage 'zibs' ('Zorginformatiebouwstenen')], in English also known as 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 were originally defined by the program ‘Registratie aan de bron’ (Data capture at the point of care). This program ended in April 2022 and maintenance and further developement of zibs was transferred to the Nictiz' zib-centrum. Zibs 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 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 were originally defined by the program ‘Registratie aan de bron’ (Data capture at the point of care). This program ended in April 2022 and maintenance and further developement of zibs was transferred to the Nictiz' zib-centrum. Zibs 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 zibs that are relevant to the situation. The formal specification for these information standards (a ~~dataset~~ constrained with cardinalities and conformance applied, comparable to what FHIR calls a ''logical model'') is linked to from the information standard specific IG.		Use cases or information standards use and refine zibs that are relevant to the situation. The formal specification for these information standards (a data set constrained with cardinalities and conformance applied, comparable to what FHIR calls a ''logical model'') is linked to from the information standard specific IG.

	===Layering: zibs, nl-core profiles and information standard specific profiles===		===Layering: zibs, nl-core profiles and information standard specific profiles===
Regel 68:		Regel 68:

	===Mapping of coded concepts===		===Mapping of coded concepts===
	Terminology from zibs or UCSDs (use case specific ~~datasets~~) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the zibs or UCSD. These cases include, but are not limited to, the FHIR resource elements of ~~datatype~~ {{datatype\|code}} (for example {{fhir\|Patient.gender}}, {{fhir\|status}} elements, structural type elements). This ~~datatype~~ always describes FHIR specific terminology, which usually doesn't align with the zibs/UCSD terminology.		Terminology from zibs or UCSDs (use case specific data sets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the zibs or UCSD. These cases include, but are not limited to, the FHIR resource elements of data type {{datatype\|code}} (for example {{fhir\|Patient.gender}}, {{fhir\|status}} elements, structural type elements). This data type always describes FHIR specific terminology, which usually doesn't align with the zibs/UCSD terminology.

	In these cases, a mapping will be provided to explain the relationship between de zib/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/R4/conceptmap.html ConceptMap], which can translate between the terminology used in the zib/UCSD, and the terminology that FHIR instances need to adhere to. This ConceptMap will be linked to the existing ValueSet using the extension [https://www.hl7.org/fhir/extension-11179-permitted-value-conceptmap.html permitted-value-conceptmap extension]. When the ConceptMap {{fhir\|equivalence}} is not {{term\|equal}} or {{term\|equivalent}}, the terminology from the zib/UCSD SHALL be communicated using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/ext-CodeSpecification ext-CodeSpecification] on the same element. It is recommended to use this extension in other {{fhir\|equivalence}}-situations as well. This allows unambiguous interpretation on the receiver end.		In these cases, a mapping will be provided to explain the relationship between de zib/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/R4/conceptmap.html ConceptMap], which can translate between the terminology used in the zib/UCSD, and the terminology that FHIR instances need to adhere to. This ConceptMap will be linked to the existing ValueSet using the extension [https://www.hl7.org/fhir/extension-11179-permitted-value-conceptmap.html permitted-value-conceptmap extension]. When the ConceptMap {{fhir\|equivalence}} is not {{term\|equal}} or {{term\|equivalent}}, the terminology from the zib/UCSD SHALL be communicated using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/ext-CodeSpecification ext-CodeSpecification] on the same element. It is recommended to use this extension in other {{fhir\|equivalence}}-situations as well. This allows unambiguous interpretation on the receiver end.
Regel 88:		Regel 88:
	</syntaxhighlight>		</syntaxhighlight>

	==Use of the reference ~~datatype~~==		==Use of the reference data type==
	A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/R4/references.html#Reference {{datatype\|Reference}} ~~datatype~~]. This ~~datatype~~ supports two modes of referencing:		A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/R4/references.html#Reference {{datatype\|Reference}} data type]. This data type supports two modes of referencing:
	; [https://hl7.org/fhir/R4/references.html#literal Literal references], using the {{fhir\|.reference}} element: A relative or absolute REST endpoint containing {{fhir\|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir\|Bundle.resource.fullUrl}}.		; [https://hl7.org/fhir/R4/references.html#literal Literal references], using the {{fhir\|.reference}} element: A relative or absolute REST endpoint containing {{fhir\|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir\|Bundle.resource.fullUrl}}.
	; [https://hl7.org/fhir/R4/references.html#logical Logical references], using the {{fhir\|.identifier}} element: Meaning a match on the business identifier ({{fhir\|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir\|.id}}) of resources.		; [https://hl7.org/fhir/R4/references.html#logical Logical references], using the {{fhir\|.identifier}} element: Meaning a match on the business identifier ({{fhir\|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir\|.id}}) of resources.
Regel 150:		Regel 150:
	===Search results===		===Search results===
	====Including referenced resources====		====Including referenced resources====
	It is possible that servers do not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference ~~datatype~~]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.		It is possible that servers do not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference data type]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

	====Paging====		====Paging====
Regel 192:		Regel 192:
	* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.		* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
	* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir\|.id}}?		* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir\|.id}}?
	* Specifically for HL7 V3 based backends: an HL7 V3 II ~~datatype~~ normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir\|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir\|.fullUrl}} consistent with the {{fhir\|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.		* Specifically for HL7 V3 based backends: an HL7 V3 II data type normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir\|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir\|.fullUrl}} consistent with the {{fhir\|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
	: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.		: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

Regel 410:		Regel 410:

	=={{fhir\|Resource.text}} or "the narrative"==		=={{fhir\|Resource.text}} or "the narrative"==
	The FHIR R4 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/R4/domainresource-definitions.html#DomainResource.text {{fhir\|.text}} element] with ~~datatype~~ [https://hl7.org/fhir/R4/narrative.html {{datatype\|Narrative}}]. This human readable text is often referred to as "the narrative".		The FHIR R4 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/R4/domainresource-definitions.html#DomainResource.text {{fhir\|.text}} element] with data type [https://hl7.org/fhir/R4/narrative.html {{datatype\|Narrative}}]. This human readable text is often referred to as "the narrative".

	This implementation guide has the following expectations regarding the use of narratives:		This implementation guide has the following expectations regarding the use of narratives:
Regel 423:		Regel 423:
	Regarding the contents of the narrative, the [https://hl7.org/fhir/R4/domainresource-definitions.html#DomainResource.text FHIR R4 spec states] that:		Regarding the contents of the narrative, the [https://hl7.org/fhir/R4/domainresource-definitions.html#DomainResource.text FHIR R4 spec states] that:
	<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>		<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
	And for the Narrative ~~datatype~~:		And for the Narrative data type:
	<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>		<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

Regel 440:		Regel 440:
	===Narrative status===		===Narrative status===

	~~Datatype~~ {{datatype\|Narrative}} [https://hl7.org/fhir/R4/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term\|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.		Data type {{datatype\|Narrative}} [https://hl7.org/fhir/R4/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term\|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

	Alternatively, status {{term\|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.		Alternatively, status {{term\|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

FHIR:V0.9 FHIR IG R4 - Bewerkingsoverzicht

Luud Slagter op 16 jun 2022 om 08:51

Luud Slagter: /* Functional definitions */

Jorn Duwel: Version 0.9