Merge branch 'master' into 185-time-synchronisation-requirements-may-…

…contradict-bpkp-requirements

CHANGELOG.md

@@ -30,7 +30,11 @@ Each section shall contain a list of action items of the following format: `<bri
 
 - Use case _Device is connected to the MD LAN network and a user wants to change the device's time_ to account for the fact, that configuring the TS service manually is always forbidden, not just when TS service is operational ([#30](https://github.com/IHE/DEV.SDPi/issues/30)).
 - Changed use case _Devices are operational in the MD LAN network but cannot access the TS Service and clock drift is unacceptable_ so that the decision to continue/discontinue the execution of a System Function while the clocks become less accurate lies with the consumer ([#31](https://github.com/IHE/DEV.SDPi/issues/31)). 
-- Open/Closed Issues sections have been revised. Sections are now generated automatically from Github issues ([#20](https://github.com/IHE/DEV.SDPi/issues/20)). 
+- Open/Closed Issues sections have been revised. Sections are now generated automatically from Github issues ([#20](https://github.com/IHE/DEV.SDPi/issues/20)).
+- Created a common section for the ACM and DEC gateways such that requirement numbers are not duplicated anymore ([#53](https://github.com/IHE/DEV.SDPi/issues/53).  
+- Rephrase R1542 to make sure, that system functions not being available don't lead to unnecessary alarms ([#180] (https://github.com/IHE/DEV.SDPi/issues/180)). 
+- Moved requirements R1542 & R1543 to the SDPi-P SES / Effectiveness section from Github issues ([#182](https://github.com/IHE/DEV.SDPi/issues/182))
+
 
 ### Removed
 

asciidoc/volume1/tf1-ch-10-sdpi-p.adoc

@@ -913,7 +913,25 @@ For additional guidance, see section <<vol1_clause_appendix_a_ses_considerations
 No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<<acronym_ses>> General Considerations_ section above.
 
 ==== Effectiveness Requirements & Considerations
-No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<<acronym_ses>> General Considerations_ section above.
+
+===== Specific Risk Control Measures for <<vol1_spec_sdpi_p_actor_somds_consumer>>s
+
+.R1542
+[sdpi_requirement#r1542,sdpi_req_level=shall]
+****
+When a <<vol1_spec_sdpi_p_actor_somds_consumer>> disables one or more <<term_system_function_contribution>>s, the <<vol1_spec_sdpi_p_actor_somds_consumer>> shall inform the affected users.
+****
+
+.R1543
+[sdpi_requirement#r1543,sdpi_req_level=shall]
+****
+If a <<vol1_spec_sdpi_p_actor_somds_consumer>> disables one or more <<term_system_function_contribution>>s, the <<vol1_spec_sdpi_p_actor_somds_consumer>> shall create a log entry, noting the disabled <<term_system_function_contribution>>s as well as the cause for disabling them.
+****
+
+===== General Risk Controls
+
+Additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<<acronym_ses>> General Considerations_ section above.
+
 ==== Security Requirements & Considerations
 Security is foundational for all interactions between <<vol1_spec_sdpi_p_actor_somds_participant>> Actors, with a clear distinction being made between information that may be exchanged outside of a secure connection (e.g., during network discovery transactions).
 Specific security technologies may vary based on the implementation technology being used, and will be detailed in the appropriate TF-2 technology specifications.
@@ -922,6 +940,7 @@ All transactions indicate whether they require secure or unsecured connections.
 For the default <<acronym_sdpi_p>> connectivity technology, namely ISO/IEEE 11073 <<term_service_oriented_device_connectivity>>, TLS 1.2 (or later versions) support is required (See <<ref_ieee_11073_20701_2018>> and <<ref_ieee_11073_20702_2016>>).
 Additional information and requirements may be provided in <<vol2_appendix_a_mdpws_messages>>.
 
+
 [#vol1_clause_sdpi_p_cross_profile_considerations]
 === SDPi-P Cross Profile Considerations
 No cross profile considerations have been identified.

asciidoc/volume1/tf1-ch-11-sdpi-r.adoc

@@ -325,6 +325,7 @@ No additional effectiveness requirements or considerations are identified for th
 ==== Security Requirements & Considerations
 No additional security requirements and considerations are identified for this technical framework element beyond those provided by the  SDPi-P profile (see <<vol1_clause_appendix_a_ses_considerations_section_template>>), and those specified in the _<<acronym_ses>> General Considerations_ section above.
 
+[#vol1_clause_sdpi_r_cross_profile_considerations]
 === SDPi-R Cross Profile Considerations
 No additional cross profile considerations have been identified.
 

asciidoc/volume1/use-cases/tf1-ch-c-use-case-stad.adoc

@@ -199,16 +199,5 @@ NOTE: This requirement supplements RR1162 in <<ref_ieee_11073_10700_2022>>: _The
 ****
 
 
-.R1542
-[sdpi_requirement#r1542,sdpi_req_level=shall]
-****
-When a <<vol1_spec_sdpi_p_actor_somds_consumer>> disables one or more <<term_system_function_contribution>>s, the <<vol1_spec_sdpi_p_actor_somds_consumer>> shall notify the user.
-****
-
-.R1543
-[sdpi_requirement#r1543,sdpi_req_level=shall]
-****
-If a <<vol1_spec_sdpi_p_actor_somds_consumer>> disables one or more <<term_system_function_contribution>>s, the <<vol1_spec_sdpi_p_actor_somds_consumer>> shall create a log entry, noting the disabled <<term_system_function_contribution>>s as well as the cause for disabling them.
-****
 
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc

@@ -17,16 +17,20 @@ This section provides an overview about the referenced standards and profiles us
 * <<ref_ieee_11073_10700_2022>>
 * <<ref_ieee_11073_10207_2017>>
 
-include::tf2-ch-b-gateway-private-mdc-mapping.adoc[]
+==== Private MDC Codes Consideration
+Please refer to general section <<ref_private_coding_system_note>>.
 
 ==== HL7 Segment Descriptions
 The following sections refer to the *Appendix B Common Segment Descriptions* of the <<ref_ihe_pcd_tf_2_2019>>.
 
-include::tf2-ch-b-gateway-msh-mapping.adoc[]
+===== MSH - Message Header Segment
+Please refer to general section <<ref_gateway_msh_mapping>>.
 
-include::tf2-ch-b-gateway-pid-mapping.adoc[]
+===== PID - Patient Identification Segment
+Please refer to general section <<ref_gateway_pid_mapping>>.
 
-include::tf2-ch-b-gateway-pv1-mapping.adoc[]
+===== PV1 - Patient Visit Segment
+Please refer to general section <<ref_gateway_pv1_mapping>>.
 
 ===== OBR - Observation Request Segment
 The HL7 Observation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields.
@@ -225,11 +229,11 @@ The OBX segments representing the alert event attributes are preceded by up to t
 
 [#ref_acm_containment_tree_mapping]
 ===== Containment Tree Hierarchy Representation
-include::tf2-ch-b-gateway-obx4-mapping.adoc[]
+Please refer to general section <<ref_gateway_obx4_mapping>>.
 
 [#ref_acm_equipment_id_mapping]
 ===== Equipment Instance Identifier Mapping
-include::tf2-ch-b-gateway-obx18-mapping.adoc[]
+Please refer to general section <<ref_gateway_obx18_mapping>>.
 
 [#ref_acm_obx_device_related_mapping]
 ====== Device-related OBX Segments
@@ -299,7 +303,7 @@ Note that this field is only required to be set for the MDS and/or the VMD eleme
 
 [#ref_acm_obs_id_mapping,sdpi_level=+1]
 ====== Observation Identifier Mapping
-include::tf2-ch-b-gateway-obx3-mapping.adoc[]
+Please refer to general section <<ref_gateway_obx3_mapping>>.
 
 [NOTE]
 ====

asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc

@@ -16,14 +16,17 @@ This section provides an overview about the referenced standards and profiles us
 * <<ref_ieee_11073_10700_2022>>
 * <<ref_ieee_11073_10207_2017>>
 
-include::tf2-ch-b-gateway-private-mdc-mapping.adoc[]
+==== Private MDC Codes Consideration
+Please refer to general section <<ref_private_coding_system_note>>.
 
 ==== HL7 Segment Descriptions
 The following sections refer to the *Appendix B Common Segment Descriptions* of the <<ref_ihe_pcd_tf_2_2019>>.
 
-include::tf2-ch-b-gateway-msh-mapping.adoc[]
+===== MSH - Message Header Segment
+Please refer to general section <<ref_gateway_msh_mapping>>.
 
-include::tf2-ch-b-gateway-pid-mapping.adoc[]
+===== PID - Patient Identification Segment
+Please refer to general section <<ref_gateway_pid_mapping>>.
 
 ===== Height and Weight Mapping
 
@@ -233,7 +236,8 @@ When there are further updates of the weight value after the association of the
 
 |===
 
-include::tf2-ch-b-gateway-pv1-mapping.adoc[]
+===== PV1 - Patient Visit Segment
+Please refer to general section <<ref_gateway_pv1_mapping>>.
 
 ===== OBR - Observation Request Segment
 The HL7 Obervation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields.
@@ -506,11 +510,11 @@ A <<actor_somds_dec_gateway>> shall leave the OBX-2 field empty for OBX segments
 |===
 
 ====== OBX-3 Observation Identifier
-include::tf2-ch-b-gateway-obx3-mapping.adoc[]
+Please refer to general section <<ref_gateway_obx3_mapping>>.
 
 [#ref_dec_obx4]
 ====== OBX-4 Observation Sub-ID
-include::tf2-ch-b-gateway-obx4-mapping.adoc[]
+Please refer to general section <<ref_gateway_obx4_mapping>>.
 
 ====== OBX-5 Observation Value
 
@@ -863,7 +867,7 @@ Or set to "AMEAS\^auto-measurement^MDC" if required.
 |===
 
 ====== OBX-18 Equipment Instance Identifier
-include::tf2-ch-b-gateway-obx18-mapping.adoc[]
+Please refer to general section <<ref_gateway_obx18_mapping>>.
 
 ====== OBX-20 Observation Site
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-msh-mapping.adoc

@@ -1,21 +1,22 @@
+[#ref_gateway_msh_mapping]
 ===== MSH - Message Header Segment
 The HL7 Message Header (MSH) segment requires a mapping between the <<acronym_mdib>> content and the MSH segment fields.
 
 .R8100
-[sdpi_requirement#r8100,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8100,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If not differently specified in this section, the MSH segment fields shall be in compliance with the [PCD-01] or [PCD-04] transaction, retrospectively, as described in the <<ref_ihe_pcd_tf_2_2019>>.
 ****
 
 .R8101
-[sdpi_requirement#r8101,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8101,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If the <<acronym_mdib>> contains several MDS elements that could operate in different *pm:MdsState/@OperatingMode* states, there shall be a separate [PCD-01] message per MDS.
 ****
 
 ====== MSH-11 Processing ID
 .R8118
-[sdpi_requirement#r8118,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8118,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 A <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the MSH-11 field to the code for the processing ID, which is either be *"P"* (Production) or *"D"* (Debugging).
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-obx18-mapping.adoc

@@ -1,4 +1,5 @@
-
+[#ref_gateway_obx18_mapping]
+===== OBX-18 Equipment Instance Identifier
 
 [%noheader]
 [%autowidth]
@@ -22,7 +23,7 @@ Another issue is that the field "Universal ID Type" of the HL7 EI date type is b
 
 
 .R8117
-[sdpi_requirement#r8117,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8117,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 A <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the OBX-18 field to the equipment (or device) identifier on the MDS level and/or the measurement module identifier of the equipment on the VMD level.
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc

@@ -1,6 +1,8 @@
+[#ref_gateway_obx3_mapping]
+===== OBX-3 Observation Identifier
 
 .R8012
-[sdpi_requirement#r8012,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8012,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 A <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the OBX-3 field to the identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric to be exported.
 
@@ -12,7 +14,7 @@ NOTE: <<ref_tbl_dec_obx3_mds_mapping>>, <<ref_tbl_dec_obx3_vmd_mapping>>, <<ref_
 ****
 
 .R8013
-[sdpi_requirement#r8013,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8013,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If a private *<<acronym_mdc>>* code is used for the coding of the SDC containment tree element, the <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall map an identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric as described in section <<ref_private_coding_system_note>>.
 ****

asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc

@@ -1,6 +1,8 @@
+[#ref_gateway_obx4_mapping]
+===== OBX-4 Observation Sub-ID
 
 .R8014
-[sdpi_requirement#r8014,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8014,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 A <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the OBX-4 field to a hierarchical representation of the SDC element in the hierarchical containment tree.
 
@@ -12,7 +14,7 @@ NOTE: Please refer to the IHE technical framework <<ref_ihe_pcd_tf_2_2019>> for
 ****
 
 .R8015
-[sdpi_requirement#r8015,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8015,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 A <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall assign the handles (which are required to be unique in the same <<acronym_mdib>>) of the containment tree elements representing MDSs, VMDs, channels and metrics to unique integer numbers per child level of the same parent.
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc

@@ -1,9 +1,10 @@
+[#ref_gateway_pid_mapping]
 ===== PID - Patient Identification Segment
 The HL7 Patient Identification (PID) segment requires a mapping from the <<acronym_mdib>> patient context information element *pm:PatientContextState* to the PID segment fields.
 
 ====== Prerequisite of Valid Patient Context
 .R8102
-[sdpi_requirement#r8102,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8102,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 The SDC patient context information shall only be mapped to the corresponding fields in the HL7 PID segment when the requirements for a valid SDC patient context as defined in <<ref_ieee_11073_10700_2022>> are fulfilled.
 
@@ -18,7 +19,7 @@ NOTE: If the SDC patient context information is not intended to be used for the
 
 ====== PID-3 Patient Identifier List
 .R8103
-[sdpi_requirement#r8103,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8103,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall map the patient identifiers to the PID-3 field.
 
@@ -90,7 +91,7 @@ The following identifier type codes are proposed to be used for the patient iden
 
 ====== PID-5 Patient Name
 .R8104
-[sdpi_requirement#r8104,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8104,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-5 field to the patient name information.
 
@@ -142,7 +143,7 @@ Please refer also to the corresponding section in the <<ref_ihe_pcd_tf_2_2019>>.
 
 ====== PID-6 Mother’s Maiden Name
 .R8105
-[sdpi_requirement#r8105,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8105,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-6 field to the mother's maiden name or birth name before marriage.
 
@@ -172,7 +173,7 @@ NOTE: <<ref_tbl_pid6_mapping>> defines the mapping of the SDC patient name infor
 
 ====== PID-7 Date/Time of Birth
 .R8106
-[sdpi_requirement#r8106,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8106,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-7 field to the date & time of birth.
 
@@ -237,7 +238,7 @@ The following list a couple of options and any comments from the reviewers are h
 |===
 
 .R8107
-[sdpi_requirement#r8107,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8107,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-8 field to the code for the administrative sex.
 
@@ -298,7 +299,7 @@ The sex and gender of a patient (or a newborn) cannot exactly be mapped from ISO
 
 ====== PID-10 Race
 .R8108
-[sdpi_requirement#r8108,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8108,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-10 field to the patient's race.
 
@@ -360,7 +361,7 @@ NOTE: <<ref_tbl_pid10_mapping>> defines the mapping of the SDC patient's race in
 
 ====== PID-31 Identity Unknown Indicator
 .R8109
-[sdpi_requirement#r8109,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8109,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-31 field to an indicator whether the patient's identity is known.
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-private-mdc-mapping.adoc

@@ -9,7 +9,7 @@ Coded elements in SDC using *<<acronym_mdc>>* private codes require also to cont
 Please refer to <<ref_ieee_11073_10700_2022>> *TR1358* for further information.
 
 .R8119
-[sdpi_requirement#r8119,sdpi_req_level=shall,sdpi_max_occurrence=2]
+[sdpi_requirement#r8119,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
 For each private code a <<vol1_spec_sdpi_p_actor_somds_provider>> shall provide exactly one *pm:Translation* where *pm:Translation/@Code* is identical with *pm:CodedValue/@Code*.