FHIR:Vissue-168 FHIR Profiling Guidelines R4 - Bewerkingsoverzicht

Pieter Edelman: /* For zibs specifically */

2022-10-24T07:11:40Z

For zibs specifically

← Oudere versie		Versie van 24 okt 2022 07:11
Regel 158:		Regel 158:
	** If the ticket results in an erratum, the fix is adopted without notice.		** If the ticket results in an erratum, the fix is adopted without notice.
	** If the error is not recognized, or won't be fixed until the next (pre-)release:		** If the error is not recognized, or won't be fixed until the next (pre-)release:
	*** If the conformance resources can be made, the error is documented with a hyperlink to the BITS ticket.		*** If the conformance resources can be made, the error is documented with a hyperlink to the BITS ticket in the suitable element, usually the {{fhir\|.comment}} field of the relevant profile element.
	*** If the conformance resources cannot be made, this is documented in the release notes using a hyperlink to the BITS ticket.		*** If the conformance resources cannot be made, this is documented in the release notes using a hyperlink to the BITS ticket.
	*** (Only) if the error pertains something trivial like a spelling mistake AND will be fixed in a future release, it is adopted without any notice.		*** (Only) if the error pertains something trivial like a spelling mistake AND will be fixed in a future release, it is adopted without any notice.

Luud Slagter: /* Handling errors, proposed changes and omissions in the functional model */

2022-10-24T06:47:13Z

Handling errors, proposed changes and omissions in the functional model

Pieter Edelman: /* Functional model as base */

2022-10-20T14:49:33Z

Functional model as base

← Oudere versie		Versie van 20 okt 2022 14:49
Regel 134:		Regel 134:

	Note that [[#Mandatory FHIR elements without a functional counterpart\|implicitly mapped elements]] and [[#References that are reversed in FHIR\|reversed references]] use a slightly different {{fhir\|comment}}.		Note that [[#Mandatory FHIR elements without a functional counterpart\|implicitly mapped elements]] and [[#References that are reversed in FHIR\|reversed references]] use a slightly different {{fhir\|comment}}.

			==Handling errors, proposed changes and omissions in the functional model==

			Conformance resources which are based on a functional model SHOULD faithfully represent the functional model. This implies that errors in the functional model ''cannot'' be fixed in the FHIR implementation unless it's really trivial; doing so would lead to a difference between the FHIR implementation and the functional model, resulting in unclear and hard to use specifications.

			Practically, this results in the following guidelines:
			<ul>
			<li>If the error is fixed on the functional level, it is adopted in the conformance resources.</li>
			<li>If an error is trivial AND recognized as something that will be fixed on the functional level, it can be adopted it (e.g. spelling mistakes).</li>
			<li>In any other case, the error will be implemented as-is in the conformance resources. This includes the following cases:<ul>
			<li>The error is not recognized as something that needs to be fixed.</li>
			<li>The error is recognized as something that needs to be fixed, but the fix has to wait until the next version.</li>
			</ul><p>The error is documented using a hyperlink to the ticket in the suitable element, usually the {{fhir\|.comment}} field of the relevant profile element.</p>
			<p>Note 1: if the error prevents the creation of the conformance resources can be created, then the functional model is deemed unimplementable and no conformance resources are created.</p>
			</ul>

			Omissions in the functional model are handled like any other error, with one important exception: if extra information is needed _in order to_ create an implementation (like a code for a functional concept), and this information will be added to a future version of the functional model, it makes sense to already adopt it for the current implementation. This addition is documented with a reference to the relevant ticket.

			===For zibs specifically===
			For zibs specifically, these guidelines are practically fulfilled in the following way.

			* For any error found in the functional model, a BITS ticket is created in the ZIB project.
			** If the ticket results in an erratum, the fix is adopted without notice.
			** If the error is not recognized, or won't be fixed until the next (pre-)release:
			*** If the conformance resources can be made, the error is documented with a hyperlink to the BITS ticket.
			*** If the conformance resources cannot be made, this is documented in the release notes using a hyperlink to the BITS ticket.
			*** (Only) if the error pertains something trivial like a spelling mistaken ''and'' will be fixed in a future release, it is adopted without any notice.
			* For missing definition codes, a BITS ticket is created in the ZIB project.
			** If the tickets results in a definition code, it is implemented in the conformance resource. The {{fhir\|.comment}} field of the element containing the code will document the code using the following remark: <q>This code aligns with the future version of this zib. See [BITS ticket]</q> for details.<q>, where [BITS ticket] should be a Markdown formatted hyperlink to the relevant ticket with the ticket key as title text.

	=Versioning=		=Versioning=

Pieter Edelman: Clone of V1.0 production page for issue 168

2022-10-20T12:38:50Z

Clone of V1.0 production page for issue 168

Wijzigingen bekijken

← Oudere versie		Versie van 24 okt 2022 06:47
Regel 142:		Regel 142:
	<ul>		<ul>
	<li>If the error is fixed on the functional level, it is adopted in the conformance resources.</li>		<li>If the error is fixed on the functional level, it is adopted in the conformance resources.</li>
	<li>If an error is trivial AND recognized as something that will be fixed on the functional level, it can be adopted it (e.g. spelling mistakes).</li>		<li>If an error is trivial AND recognized as something that will be fixed on the functional level, it can be adopted (e.g. spelling mistakes).</li>
	<li>In any other case, the error will be implemented as-is in the conformance resources. This includes the following cases:<ul>		<li>In any other case, the error will be implemented as-is in the conformance resources. This includes the following cases:<ul>
	<li>The error is not recognized as something that needs to be fixed.</li>		<li>The error is not recognized as something that needs to be fixed.</li>
	<li>The error is recognized as something that needs to be fixed, but the fix has to wait until the next version.</li>		<li>The error is recognized as something that needs to be fixed, but the fix has to wait until the next version.</li>
	</ul><p>The error is documented using a hyperlink to the ticket in the suitable element, usually the {{fhir\|.comment}} field of the relevant profile element.</p>		</ul><p>The error is documented using a hyperlink to the ticket in the suitable element, usually the {{fhir\|.comment}} field of the relevant profile element.</p>
	<p>Note 1: if the error prevents the creation of the conformance resources ~~can be created~~, then the functional model is deemed unimplementable and no conformance resources are created.</p>		<p>Note: if the error prevents the creation of the conformance resources, then the functional model is deemed unimplementable and no conformance resources are created.</p>
	</ul>		</ul>

	Omissions in the functional model are handled like any other error, with one important exception: if extra information is needed ~~_in~~ order ~~to_~~ create an implementation (like a code for a functional concept), and this information will be added to a future version of the functional model, it makes sense to already adopt it for the current implementation. This addition is documented with a reference to the relevant ticket.		Omissions in the functional model are handled like any other error, with one important exception: if extra information is needed ''in order to'' create an implementation (like a code for a functional concept), and this information will be added to a future version of the functional model, it makes sense to already adopt it for the current implementation. This addition is documented with a reference to the relevant ticket.

	===For zibs specifically===		===For zibs specifically===
Regel 160:		Regel 160:
	*** If the conformance resources can be made, the error is documented with a hyperlink to the BITS ticket.		*** If the conformance resources can be made, the error is documented with a hyperlink to the BITS ticket.
	*** If the conformance resources cannot be made, this is documented in the release notes using a hyperlink to the BITS ticket.		*** If the conformance resources cannot be made, this is documented in the release notes using a hyperlink to the BITS ticket.
	*** (Only) if the error pertains something trivial like a spelling ~~mistaken ''and''~~ will be fixed in a future release, it is adopted without any notice.		*** (Only) if the error pertains something trivial like a spelling mistake AND will be fixed in a future release, it is adopted without any notice.
	* For missing definition codes, a BITS ticket is created in the ZIB project.		* For missing definition codes, a BITS ticket is created in the ZIB project.
	** If the tickets results in a definition code, it is implemented in the conformance resource. The {{fhir\|.comment}} field of the element containing the code will document the code using the following remark: <q>This code aligns with the future version of this zib. See [BITS ticket]</q> for details.<q>, where [BITS ticket] should be a Markdown formatted hyperlink to the relevant ticket with the ticket key as title text.		** If the tickets results in a definition code, it is implemented in the conformance resource. The {{fhir\|.comment}} field of the element containing the code will document the code using the following remark: <q>This code aligns with the future version of this zib. See [BITS ticket]</q> for details.<q>, where [BITS ticket] should be a Markdown formatted hyperlink to the relevant ticket with the ticket key as title text.