Corrected use of bracketed numbers throughout & removed em-dash after…

… "4 Profiles"

asciidoc/sdpi-supplement-intro.adoc

@@ -28,7 +28,7 @@ It is recognized that this release is a work-in-progress that will continue to s
 These known limitations and forward-looking content include:
 
 . Releases along with the planned capability additions are managed in the project's https://github.com/orgs/IHE/projects/6[DEV.SDPi "Gemini SDPi Releases" Github project]
-. This supplement includes (4) SDPi Profiles, though the typical IHE supplement is organized for a single profile; as a result, some adjustments have been made, especially in the supplement overview section where there is a general SDPi overview and then basic overviews for each of the Profiles; challenging areas include profile "options" where there are FOUR sections vs. one; it is a work in progress and feedback is appreciated, especially to enhance clarity
+. This supplement includes four SDPi Profiles, though the typical IHE supplement is organized for a single profile; as a result, some adjustments have been made, especially in the supplement overview section where there is a general SDPi overview and then basic overviews for each of the Profiles; challenging areas include profile "options" where there are FOUR sections vs. one; it is a work in progress and feedback is appreciated, especially to enhance clarity
 . *Open / Closed Issues tables* -- starting with SDPi 1.1 and subsequent, the approach for the IHE open / closed issues section has been transitioned to utilize https://github.com/IHE/DEV.SDPi/issues[Github Issues] that are related to this release; each release will update the changelog file, detailing what is Added, Changed or Removed
 . *Requirements boxes* (e.g., "R1234") have been added especially in TF-2, with some also part of TF-1 and TF-3; this is an initial approach that *_will be significantly expanded in future versions of the supplement_*; documentation is provided in <<vol1_clause_sdpi_requirements_modeling_integration>>, including discussion related to how it will be expanded in future versions of the supplement;
 . *_<<term_safe_effective_secure>> Sections_* (see <<vol1_clause_appendix_a_ses_considerations_section_template>>) are included in the specification; however, their use and content will be significantly extended in future versions;
@@ -47,14 +47,14 @@ include::document-declarations.adoc[]
 [#supplement_clause_sdpi_supplement_organization]
 === SDPi Supplement Organization
 
-This IHE Devices Technical Framework supplement introduces a new _family of interoperability profiles_, Service-oriented Device Point-of-care Interoperability (SDPi), that comprise (4) separate profiles:
+This IHE Devices Technical Framework supplement introduces a new _family of interoperability profiles_, Service-oriented Device Point-of-care Interoperability (SDPi), that comprise four separate profiles:
 
 * SDPi-Plug-and-trust (*SDPi-P*) Profile
 * SDPi-Reporting (*SDPi-R*) Profile
 * SDPi-Alerting (*SDPi-A*) Profile
 * SDPi-external Control (*SDPi-xC*) Profile
 
-To that end, the supplement includes updates to all (3) IHE DEV TF volumes, including:
+To that end, the supplement includes updates to all three IHE DEV TF volumes, including:
 
 *TF-1  Profiles*
 

asciidoc/volume0/tf0-ch-d-glossary.adoc

@@ -326,7 +326,7 @@ elements, from requirements to system components to Verification & Validation te
 | SDC
 
 | [[term_service_oriented_device_poc_interoperability,Service-oriented Device Point of Care Interoperability (SDPi)]] Service-oriented Device Point of Care Interoperability
-| A set of (4) IHE specifications that profile the <<acronym_sdc>> standards for device-to-device plug-and-play interoperability.
+| A set of four IHE specifications that profile the <<acronym_sdc>> standards for device-to-device plug-and-play interoperability.
 |
 | [[acronym_sdpi,SDPi]] SDPi
 |

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

@@ -779,7 +779,7 @@ From a conceptual perspective, <<acronym_sdc>> implements a <<acronym_soa>> arch
 [#figure_general_soa_model]
 image::../images/vol1-diagram-sdc-soa-conceptual-model.svg[align=center]
 
-This generalized model includes (3) system roles:
+This generalized model includes three system roles:
 
 . *Service Providers* -- indicate the capabilities or services that they support, often published to a centralized registry that all participating systems recognize;
 
@@ -799,7 +799,7 @@ This generalized model includes (3) system roles:
 
 NOTE:  A detailed overview of <<acronym_soa>> concepts is beyond the scope of this specification.  See <<vol1_appendix_b_references>> for additional background materials.
 
-The <<acronym_sdc>> <<acronym_biceps>> standard, which SDPi-P profiles, consists of (3) core components, as illustrated in <<figure_sdc_biceps_components_model>>:
+The <<acronym_sdc>> <<acronym_biceps>> standard, which SDPi-P profiles, consists of three core components, as illustrated in <<figure_sdc_biceps_components_model>>:
 
 .SDC/BICEPS Components Model
 [#figure_sdc_biceps_components_model]

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

@@ -12,7 +12,7 @@ a| *{supplement_note}*: This supplement is being written after the 2019 reorgani
 It is intended to amend a new IHE DEV Technical Framework (TF), that covers the expanded areas not only of PCD devices (enterprise integration focused), but also Personal Connected Health (*PCH*) devices and Device Point-of-care Interoperability (*DPI*) for device-to-device integration around an acute point-of-care (e.g., operating room table, ICU bed, emergency department bed, etc.).
 As a result of these basic changes in the scope and organization of the IHE DEV domain, some additional TF sections have been proposed to help the community understand how these technical specifications are integrated.  For example,
 
-. Section(s) for General IHE Devices architecture, use contexts, and (4) <<term_participant_key_purposes>> functions -- Connecting, Reporting, Alerting, and Controlling (external)
+. Section(s) for General IHE Devices architecture, use contexts, and four <<term_participant_key_purposes>> functions -- Connecting, Reporting, Alerting, and Controlling (external)
 . Section addressing "What is a device?" (aligned with a similar topic within the joint IHE-HL7 Gemini project); especially relevant given the differences between <<term_personal_health_device>> and <<term_point_of_care_device>> as well as the increasing prevalence of <<term_software_as_a_medical_device>> applications.  (See https://confluence.hl7.org/x/Iw7xB["Paper:  What is a device?"] for additional background.)
 
 These general concepts will help the technical framework reader understand the broader context into which the profile specifications are intended to be implemented.
@@ -81,7 +81,7 @@ The SDPi Profiles are built upon a foundation of standards and profiles from <<a
 [#figure_sdpi_profiles_foundational_standards]
 image::../images/vol1-diagram-sdpi-profiles.svg[align=center]
 
-There is a particular challenge with SDPi profiling of <<acronym_sdc>> that resulted in the definition of (4) profiles and not one:
+There is a particular challenge with SDPi profiling of <<acronym_sdc>> that resulted in the definition of four profiles and not one:
 
 [none]
 . *__How to represent a <<acronym_soa>>-based architecture supporting an interactive <<term_plug_and_trust>> device-to-device (multi-way, M:N) interoperability specification using established IHE technical framework constructs? __*
@@ -94,7 +94,7 @@ Or IHE "gateway" actors include mappings to the foundational, non-SDC standards.
 The above figure illustrates how this balance was achieved, including:
 
 [none]
-. *4 Profiles* --
+. *Four Profiles*
 [none]
 .. By separating SDPi into four separate but integrated profiles, the complexity of the <<term_plug_and_trust>> system-to-system interactions + the optionality of real-world systems is better managed.
 . *Gateway Actors*
@@ -110,7 +110,7 @@ The above figure illustrates how this balance was achieved, including:
 .. These standards represent shared or consensus risk management requirements (e.g., risk mitigations) that together address how to implement <<acronym_ses>> interoperable *medical device* technologies.
 .. The diagram illustrates how the <<acronym_sdc>> Core Standards provide for basic healthcare connectivity; whereas the <<acronym_pkp>> standards add a requirements layer for devices that have a *_medical interoperability purpose_*.
 
-"**PRAC**tical" Device Interoperability may be a bit "cute"; however, it does map to the (4) Profiles, which together provide a practical, pragmatic way toward genuine <<acronym_pnt>> interoperability:
+"**PRAC**tical" Device Interoperability may be a bit "cute"; however, it does map to the four Profiles, which together provide a practical, pragmatic way toward genuine <<acronym_pnt>> interoperability:
 
 [none]
 . P -> SDPi-Plug-and-trust