Addressed 3 JIRA tickets listed in issue #275

asciidoc/sdpi-supplement-intro.adoc

@@ -58,7 +58,7 @@ To that end, the supplement includes updates to all (3) IHE DEV TF volumes, incl
 
 *TF-1  Profiles*
 
-* General overview of the SDPi architectural approach & integrated set of profiles
+* General overview of the SDPi architectural approach and integrated set of profiles
 * Profile-specific sections
 * Related appendices, for example the integration of this family of SDPi Profiles with other sources of requirements - use cases or reference standards
 
@@ -96,7 +96,7 @@ These three objectives may be summarized as follows:
 [none]
 * *Requirements Interoperability (RI)*
 [none]
-** Ability to integrate & automate requirements and capabilities from component specifications & standards to enable traceability & coverage at <<term_conformity_assessment>> (<<acronym_ca>>) of the component product interface
+** Ability to integrate and automate requirements and capabilities from component specifications and standards to enable traceability and coverage at <<term_conformity_assessment>> (<<acronym_ca>>) of the component product interface
 * *Model Centric (MC)*
 [none]
 ** Transition from a document-centric to a _computable model-based "single source of truth"_ specification from which the Technical Framework becomes a view of the model
@@ -105,10 +105,10 @@ These three objectives may be summarized as follows:
 ** Enable CA test reports that are genuinely _"regulatory submission ready"_ (e.g., inclusion in a U.S. FDA 510(k) submission package)
 
 The SDPi {ihe_supplement_sdpi_revision} version of the supplement continues to make small but significant steps toward support of these objectives, especially Requirements Interoperability, as well as the use of AsciiDoc metadata to annotate the document sources for post-processing.
-Clearly, moving toward <<term_model_centric>> specifications and full integration of <<term_model_based_systems_engineering>> (<<acronym_mbse>>) will take considerable effort and time; however, this supplement represents a humble start in that direction.
+Clearly, moving toward <<term_model_centric>> specifications and full integration of <<term_model_based_systems_engineering>> will take considerable effort and time; however, this supplement represents a humble start in that direction.
 Subsequent supplement versions will build upon these objectives and support a new level of rigor for connectathon and product conformity assessment testing and ultimately test reports that directly impact the challenges around medical product regulatory submissions.
 
-Additional discussion is provided in <<vol1_appendix_a_requirements_management_for_p_n_t_interperability>>, and on the https://confluence.hl7.org/pages/viewpage.action?pageId=82906664#ConformityAssessment&Tooling-RI+MC+RRforMedTechSpecificationsInitiative[Gemini project's confluence pages].
+Additional discussion is provided in <<vol1_appendix_a_requirements_management_for_p_n_t_interperability>>, and on the https://confluence.hl7.org/pages/viewpage.action?pageId=82906664#ConformityAssessment&Tooling-RI+MC+RRforMedTechSpecificationsInitiative[Gemini project's Confluence pages].
 See also related discussions on the Gemini Project's https://confluence.hl7.org/x/XhPUB[Pathway to an Ecosystem of Plug-and-Trust Products].
 
 

asciidoc/sdpi-supplement-issues.adoc

@@ -12,7 +12,7 @@ Filter the issues on "Topic of Interest" to see a full list.  +
 * To see the full list of OPEN issues, filter on: is:issue is:open label:"Topic of Interest"
 * To see the full list of CLOSED issues, filter on: is:issue is:closed label:"Topic of Interest"
 
-For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#overview-from-discussion-to-planning-to-development[_Overview: From Discussion to Planning to Development_] and the confluence article https://confluence.hl7.org/pages/viewpage.action?pageId=82912211#TopicsofInterest-TopicResolutionWorkflow[_Topics of Interest -- Topic Resolution Workflow_].
+For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#overview-from-discussion-to-planning-to-development[_Overview: From Discussion to Planning to Development_] and the Confluence article https://confluence.hl7.org/pages/viewpage.action?pageId=82912211#TopicsofInterest-TopicResolutionWorkflow[_Topics of Interest -- Topic Resolution Workflow_].
 
 [sdpi_offset=clear]
 === Open Issues and Topic of Interests

asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc

@@ -16,7 +16,7 @@ Requirement Definition (this table's rows) will be referenced where they are sat
 
 ===== General
 
-WARNING:  GEN-1 & GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions.
+WARNING:  GEN-1 and GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions.
 
 ADD IEEE:  *Table 20 -- General ICSs table here*
 

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

@@ -15,8 +15,8 @@ All the SDPi-P actors are therefore scoped with “<<acronym_somds>>” to clear
 
 Although all information exchanged between SDPi-P <<acronym_somds>> participating systems and applications must conform to the basic <<acronym_sdc>>/<<acronym_biceps>> content module requirements footnote:[See <<vol3_clause_sdc_biceps_semantic_content_module>>. ], content modules have been defined for common high-acuity medical devices such as infusion pumps, ventilators and physiologic monitors.
 
-Note that future IHE _workflow profiles_ may be defined that build upon the transport & content module foundation established by the SDPi-P profile.
-For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU & Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction.
+Note that future IHE _workflow profiles_ may be defined that build upon the transport and content module foundation established by the SDPi-P profile.
+For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU / Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction.
 
 
 [#vol1_clause_sdpi_p_actors_transactions_content_modules,sdpi_offset=1]
@@ -27,7 +27,7 @@ For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Ca
 [cols="1"]
 |===
 a| *{supplement_note}*: Some actors and transactions have been deferred to a subsequent version, but are included here for completeness.
-Specifically:  SOMDS FHIR Gateway, SOMDS Sensor Gateway & SOMDS Smart App Platform, have been deferred.
+Specifically:  SOMDS FHIR Gateway, SOMDS Sensor Gateway and SOMDS Smart App Platform, have been deferred.
 
 Deferred transactions have been so indicated in the transactions table.
 

asciidoc/volume1/tf1-ch-2-overview.adoc

@@ -202,12 +202,12 @@ Given the significant risks associated with allowing device-external control fun
 | <<acronym_sdpi_r>>
 | Device Enterprise Communication (DEC))
 | The <<actor_somds_dec_gateway>> integrates DEC Device Observation Reporter (DOR) Actor specifications.
-| Required for mapping from <<acronym_sdc>> & <<acronym_biceps>>  to HL7 V2 and DEC transactions.
+| Required for mapping from <<acronym_sdc>> and <<acronym_biceps>>  to HL7 V2 and DEC transactions.
 
 | <<acronym_sdpi_a>>
 | Alert Communication Management (ACM)
 | The <<actor_somds_acm_gateway>> integrates ACM Alert Reporter (AR) Actor specifications.
-| Required for mapping from <<acronym_sdc>> & <<acronym_biceps>>  to HL7 V2 and ACM transactions.
+| Required for mapping from <<acronym_sdc>> and <<acronym_biceps>>  to HL7 V2 and ACM transactions.
 
 |===
 

asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc

@@ -52,7 +52,7 @@ NOTE:  The implementation of this high-level framework will be extended as the s
 [#vol1_appendix_a_integrating_ses]
 === Integrating Safety, Effectiveness and Security Requirements and Considerations
 
-In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched -- Joint Working Group 7 (JWG7) -- to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned & managed) networking infrastructure.
+In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched -- Joint Working Group 7 (JWG7) -- to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned and managed) networking infrastructure.
 The resulting standard, <<ref_iec_80001_1_2021>>, with a first edition published in 2010 and revised in 2021, not only provided a process for performing coordinated multi-stakeholder risk management for these technologies, but recognized the three *key properties* that would be the focus of that risk management:  *_Safety, Effectiveness & Security (SES)_* footnote:ses_definitions[For definitions of these and other related terms, consult the https://81001.org[NHS 81001.org web page.] Last accessed 2022.10.04.].
 
 During the development of the 80001-1 standard, though, it was recognized that risk management is just one of a number of other core themes that had to be managed in concert (e.g., quality management, human factors / usability).
@@ -65,7 +65,7 @@ image::../images/vol1-diagram-81001-temple.svg[algin=center]
 . Source:  <<ref_iso_81001_temple>>
 
 One of the key challenges for implementing this standard, though, is what might be labeled:  *_The Interoperability Trust Gap_*.
-This is the technology "hand off" space between the left side of the lifecycle -- Design and development phase, where key responsibility is by each of the "Accountable Manufacturer" organizations, and the right side of the lifecycle -- Implementation phase & Clinical use phase, where key responsibility is on the Accountable Healthcare Delivery Organization (HDO).
+This is the technology "hand off" space between the left side of the lifecycle -- Design and development phase, where key responsibility is by each of the "Accountable Manufacturer" organizations, and the right side of the lifecycle -- Implementation phase and Clinical use phase, where key responsibility is on the Accountable Healthcare Delivery Organization (HDO).
 Though this reads well in the standards and the model organizes everything in a clear fashion, operationalizing this in real world use remains a Sisyphean effort, primarily due to the amount of expertise, time and resources needed to effectively implement the SES standards as part of normal operating business in HDOs.
 
 To address this <<acronym_ses>> implementation problem, the SDPi Profiles:

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

@@ -150,7 +150,7 @@ A <<actor_somds_acm_gateway>> shall set the OBR-4 field to *"196616\^MDC_EVT_ALA
 .R8055
 [sdpi_requirement#r8055,sdpi_req_level=shall]
 ****
-A <<actor_somds_acm_gateway>> shall set the OBR-7 field to the date & time at which the Alert Reporter (AR) of the IHE ACM gateway created the alert event message to be sent.
+A <<actor_somds_acm_gateway>> shall set the OBR-7 field to the date and time at which the Alert Reporter (AR) of the IHE ACM gateway created the alert event message to be sent.
 
 .Notes
 [%collapsible]
@@ -355,7 +355,7 @@ NOTE: This either applies to a change of the *pm:AlertConditionState* or the *pm
 
 NOTE: The date/time to be set in the OBX-14 field relates to the alert event phase. <<ref_tbl_acm_obx14_alert_phase_mapping>> defines the date/time mapping per alert event phase.
 
-NOTE: The HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (please refer to <<ref_expl_dt_mapping>> for further information).
+NOTE: The HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (please refer to <<ref_expl_dt_mapping>> for further information).
 ====
 ****
 

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

@@ -143,7 +143,7 @@ When there are further updates of the height value after the association of the
 |OBX-14
 |Date/Time of the Observation
 |pm:PatientContextState+++<wbr/>+++/@BindingStartTime
-|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
+|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
 
 |===
 
@@ -232,7 +232,7 @@ When there are further updates of the weight value after the association of the
 |OBX-14
 |Date/Time of the Observation
 |pm:PatientContextState+++<wbr/>+++/@BindingStartTime
-|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
+|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
 
 |===
 
@@ -784,7 +784,7 @@ NOTE: <<ref_tbl_dec_obx14_mapping>> defines the mapping of the SDC metric measur
 pm:NumericMetricState+++<wbr/>+++/pm:MetricValue+++<wbr/>+++/@DeterminationTime
 
 pm:StringMetricState+++<wbr/>+++/pm:MetricValue+++<wbr/>+++/@DeterminationTime
-|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
+|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
 
 |===
 

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

@@ -175,7 +175,7 @@ NOTE: <<ref_tbl_pid6_mapping>> defines the mapping of the SDC patient name infor
 .R8106
 [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.
+If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gateway>> shall set the PID-7 field to the date and time of birth.
 
 .Notes
 [%collapsible]
@@ -192,7 +192,7 @@ NOTE: <<ref_tbl_pid7_mapping>> defines the mapping of the SDC patient's date of
 |PID-7/DTM-1
 |Date/Time
 |pm:PatientContextState+++<wbr/>+++/pm:CoreData+++<wbr/>+++/pm:DateOfBirth
-|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
+|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
 
 |===
 
@@ -305,7 +305,7 @@ When there are further updates of the sex value after the association of the pat
 |OBX-14
 |Date/Time of the Observation
 |pm:PatientContextState+++<wbr/>+++/@BindingStartTime
-|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
+|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <<ref_expl_dt_mapping>>).
 
 |===
 

asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-gender.adoc

@@ -6,7 +6,7 @@
 [cols="1"]
 |===
 a| *{supplement_note}*: As mentioned in the main text below, <<acronym_biceps>> does not currently provide sex and gender semantic support at the same level of detail as foundational existing and emerging standards.
-The following sex & gender harmonization policy will be taken in this and future SDPi specification versions until clear direction is available.
+The following sex and gender harmonization policy will be taken in this and future SDPi specification versions until clear direction is available.
 
 [none]
 . *STANDARDIZATION NOTE:*  There is active work to finalize the informatics standards related to sex and gender, including within HL7, SNOMED, ISO/TC215 and in other standards development organizations.