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

Luud Slagter op 13 sep 2023 om 07:33

2023-09-13T07:33:43Z

2023-09-08T12:40:39Z

‎Metadata on the StructureDefinition root

2023-09-08T07:42:11Z

‎SearchParameters

2023-09-08T07:41:01Z

‎For zibs specifically

2023-09-08T07:40:26Z

‎For zibs specifically

2023-09-08T07:35:32Z

2023-09-08T07:35:00Z

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

@@ Regel 562: / Regel 562: @@
 [https://zibs.nl/wiki/HealthProfessional-v3.5(2020EN) Zib HealthProfessional] is mapped onto two profiles: one on FHIR resource PractitionerRole (zib-HealthProfessional-PractitionerRole) and one on FHIR resource Practitioner (zib-HealthProfessional-Practitioner). The PractitionerRole resource covers the recording of the location and types of services that HealthProfessionals are able to provide for a HealthcareProvider, whereas the Practitioner resource captures the personal information, including the identifiers of the health professional.
-In FHIR, it is usually possible to define a reference to either resource. However, the reference to this zib from other zibs will be modelled in the following way:
+In FHIR, it is usually possible to define a reference to either resource. However, the reference to this zib from other zibs will be modeled in the following way:
 * Only zib-HealthProfessional-PractitionerRole is added to the list of target resources.
 * As described in [[#Constraining references]], no restrictions on the base Practitioner or PractitionerRole are made.

@@ Regel 458: / Regel 458: @@
 *** For standard specific profiles: a description with a reference to the base profile, with an explanation of why it has been added.
 ** For extensions:
-*** For extension representing a specific concept: <q>This extension represents the ''[concept name]'' of ''[name of the building block]]''</q>, followed by a link to the functional description.
+*** For extension representing a specific concept: <q>This extension represents the ''[concept name]'' concept of ''[name of the building block]]''</q>, followed by a link to the functional description.
 *** For other extensions this will usually be absent.
 ** Note: for extensions and datatype profiles, guidance for profilers may be placed here as well.

@@ Regel 404: / Regel 404: @@
 ====SearchParameters====
-SearchParameters are generally added from the nl-core layer onwards because the zib layer is without an use case definition.
+SearchParameters are generally added from the nl-core layer onwards because the zib layer is without a use case definition.
 *The code should consist of one or multiple words in lowercase ASCII characters, with multiple words separated using a dash ("-"):
 ** If the search parameter doesn't pertain to a specific functional model or use case, the FHIR element that the search parameter acts on should be used.

@@ Regel 172: / Regel 172: @@
 *** (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.
-** If the ticket 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 ticket 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] for details.</q>, where [BITS ticket] should be a Markdown formatted hyperlink to the relevant ticket with the ticket key as title text.
 =Versioning=

@@ Regel 172: / Regel 172: @@
 *** (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.
-** 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 ticket 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=

@@ Regel 475: / Regel 475: @@
 ** The Dutch zib concept names are placed on {{fhir|element.alias}}
 * For elements that bind ValueSets:
-** 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:
 ** 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.