IHE · ToddCooper · Oct 4, 2024 · Oct 2, 2024 · Oct 2, 2024 · Oct 2, 2024
diff --git a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc
@@ -644,7 +644,7 @@ The addition of a <<vol1_spec_sdpi_p_actor_discovery_proxy>> Actor enables a sec
 The <<vol1_spec_sdpi_p_actor_discovery_proxy>> Actor acts as a man-in-the-middle system, with <<vol1_spec_sdpi_p_actor_somds_provider>> Actors using the <<vol2_clause_dev_46>> transaction to provide endpoint metatdata and update their network presence or absence status.
 <<vol1_spec_sdpi_p_actor_somds_consumer>> Actors may then use the <<vol2_clause_dev_47>> transaction to determine available <<vol1_spec_sdpi_p_actor_somds_consumer>> systems and their endpoint metadata.
 
-<<figure_sdpi-p-managed-discovery-option-sequence-diagram>> provides an overview of the interactions of the SOMDS Consumer and Somes Provider Actors with the Discovery Proxy Actor.
+<<figure_sdpi-p-managed-discovery-option-sequence-diagram>> provides an overview of the interactions of the SOMDS Consumer and SOMDS Provider Actors with the Discovery Proxy Actor.
 
 .SDPi-P Managed Discovery Option - transaction Sequence Diagram
 [#figure_sdpi-p-managed-discovery-option-sequence-diagram]
@@ -804,7 +804,7 @@ image::../images/vol1-diagram-sdc-biceps-component-view.svg[align=center]
 
 The <<term_medical_data_information_base>> component applies to all participating systems and consists of a *_descriptive model_* (e.g., what services and information a <<vol1_spec_sdpi_p_actor_somds_provider>> supports), and a state model.
 The discovery and communications models combine to enable device-to-device messaging and to identify both systems and services available on the network.
-The descriptive model is covered in more detail in <<vol3_clause_sdc_biceps_semantic_content_module>>, but the following <<figure_sdc_biceps_mdib_descriptors_states>> shows how network efficiency is achieved by searating descriptive information from dynamic state information:
+The descriptive model is covered in more detail in <<vol3_clause_sdc_biceps_semantic_content_module>>, but the following <<figure_sdc_biceps_mdib_descriptors_states>> shows how network efficiency is achieved by separating descriptive information from dynamic state information:
 
 .SDC/BICEPS MDIB Descriptors & States
 [#figure_sdc_biceps_mdib_descriptors_states]

diff --git a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc
@@ -5,7 +5,7 @@
 == Requirements Management for Plug-and-Trust Interoperability
 
 
-These SDPi specifications include the model-centric integration of requirements from multiple sources -- both within IHE and from other <<acronym_sdo>>s -- enabling a new level of *requirements management* that provides new value to all stakeholders.  Also termed *_<<term_requirements_interoperability>>_*, innovative capabilties include:
+These SDPi specifications include the model-centric integration of requirements from multiple sources -- both within IHE and from other <<acronym_sdo>>s -- enabling a new level of *requirements management* that provides new value to all stakeholders.  Also termed *_<<term_requirements_interoperability>>_*, innovative capabilities include:
 
 . Explicit linking of requirements from their definition to their satisfaction / utilization in defined _capabilities_;
 . Explicit linking of requirements from external sources (e.g., normative standards references) to where they are supported in the profile specification, either completely, partially, unsupported or out-of-scope;

diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-60601-1-8.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-60601-1-8.adoc
@@ -26,7 +26,7 @@ The other models are anticipated for subsequent versions.
 
 *CDIS* is a system for reporting alarm signals with no technical confirmation but with operator confirmation (accept/reject).
 
-NOTE: CDIS is not recognized in 60601-1-8, however it is implemented in practise and therefore included
+NOTE: CDIS is not recognized in 60601-1-8, however it is implemented in practice and therefore included
 
 
 • Cannot rely on it for alarm signaling as a risk control
@@ -174,11 +174,11 @@ Examples include:
 ====== DAS - DISTRIBUTED ALARM SYSTEM
 ALARM SYSTEM that involves more than one item of equipment in a ME SYSTEM intended for delivery of ALARM CONDITIONS with technical confirmation
 
-NOTE: NOTE 1 The parts of a DISTRIBUTED ALARM SYSTEM can be widely separated in distance.
+NOTE: NOTE 1: The parts of a DISTRIBUTED ALARM SYSTEM can be widely separated in distance.
 
-NOTE: NOTE 2 A DISTRIBUTED ALARM SYSTEM is intended to notify OPERATORS of the existence of an ALARM CONDITION.
+NOTE: NOTE 2: A DISTRIBUTED ALARM SYSTEM is intended to notify OPERATORS of the existence of an ALARM CONDITION.
 
-NOTE: NOTE 3 For the purposes of this document, technical confirmation means that each element of a DISTRIBUTED ALARM SYSTEM confirms or guarantees the successful delivery of the ALARM CONDITION to the next element or appropriate TECHNICAL ALARM CONDITIONS are created as described in clause 6.11.2.2.1 of <<ref_iec_60601_1_8_2020>>.
+NOTE: NOTE 3: For the purposes of this document, technical confirmation means that each element of a DISTRIBUTED ALARM SYSTEM confirms or guarantees the successful delivery of the ALARM CONDITION to the next element or appropriate TECHNICAL ALARM CONDITIONS are created as described in clause 6.11.2.2.1 of <<ref_iec_60601_1_8_2020>>.
 
 .IEC 60601-1-8:2020, Figure 2 -- Functions of a DISTRIBUTED ALARM SYSTEM utilizing a MEDICAL IT NETWORK
 image::../images/vol1-diagram-60601-1-8-2020-figure-2.svg[]

diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-use-case-acns.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-use-case-acns.adoc
@@ -8,7 +8,7 @@
 Bonjour Hospital is in the process of installing a nurse alert notification system which will communicate alerts from the ICU devices (patient monitors, ventilators, infusion devices, etc.) directly to nurse devices such as pagers or smartphones.  Bobby Thornton is responsible for integrating data from their ICU devices with the alert notification system.  Once they are done, the alerts from the devices will be forwarded by the gateway to the nurse devices for viewing in a timely manner.
 
 ==== Benefits
-The ability of the system to share alert events directly with the responsible nurse allows that nurse to be aware of issues with the patient without being next to or near the patient.  It is also the first step in implementing a Quiet Hospital or Silent Hospital approach where alerts are not signalled at the patient bedside thereby reducing the amount of noise that the patient is subjected to and improving their ability to recuperate.
+The ability of the system to share alert events directly with the responsible nurse allows that nurse to be aware of issues with the patient without being next to or near the patient.  It is also the first step in implementing a Quiet Hospital or Silent Hospital approach where alerts are not signaled at the patient bedside thereby reducing the amount of noise that the patient is subjected to and improving their ability to recuperate.
 
 ==== Technical View
 

diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-use-case-sicdmp.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-use-case-sicdmp.adoc
@@ -39,13 +39,13 @@ image::../images/vol1-diagram-use-case-sicdmp-tech-view.svg[]
 
 *Then* the Dashboard will display parameter, waveform, setting, alarm, imaging, etc. information from those devices (based on configuration)
 
-===== Scenario: <<acronym_sicdmp>> {var_use_case_id}.2 - ICU Devices are Inccessible to the Dashboard
+===== Scenario: <<acronym_sicdmp>> {var_use_case_id}.2 - ICU Devices are Inaccessible to the Dashboard
 
 *Given* Dashboard cannot detect any assigned accessible ICU devices
 
 *Then* the Dashboard will display an error message
 
-===== Scenario: <<acronym_sicdmp>> {var_use_case_id}.3 - One or more ICU Devices are Inccessible to the Dashboard
+===== Scenario: <<acronym_sicdmp>> {var_use_case_id}.3 - One or more ICU Devices are Inaccessible to the Dashboard
 
 *Given* Dashboard cannot detect any previously assigned accessible ICU devices
 

diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc
@@ -14,7 +14,7 @@
 | *{supplement_note}*: This initial section of Appendix C is informative and is still being detailed.  Completion is deferred to version 1.x or later.
 It provides general background detail around how general (non-technology specific) clinical use case specifications are being utilized in this supplement.
 
-*REVIEWER QUESTION*:  Please review the intended topics and identify any additional content that should be considered.  Especialy helpful would be references to related standards and materials that would inform the approach taken in this appendix.
+*REVIEWER QUESTION*:  Please review the intended topics and identify any additional content that should be considered.  Especially helpful would be references to related standards and materials that would inform the approach taken in this appendix.
 |===
 
 ////

diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc
@@ -72,7 +72,7 @@ For the *initial alert event announcement message*, a <<actor_somds_acm_gateway>
 .Notes
 [%collapsible]
 ====
-NOTE: This identifer consists of the *pm:AlertConditionState/@DescriptorHandle*  plus the *SequenceId* plus the *pm:AlertConditionState/@StateVersion* of the state report.
+NOTE: This identifier consists of the *pm:AlertConditionState/@DescriptorHandle*  plus the *SequenceId* plus the *pm:AlertConditionState/@StateVersion* of the state report.
 ====
 
 .Examples
@@ -647,7 +647,7 @@ A <<actor_somds_acm_gateway>> shall set the OBX-4 Observation Sub-ID to *"<MDS>.
 A <<actor_somds_acm_gateway>> shall set the OBX-11 Observation Result Status to *"R"*.
 ****
 
-.OBX Source Identification Mapping - Pysiological Alert Event
+.OBX Source Identification Mapping - Physiological Alert Event
 ====
 OBX|5|NM|150037\^MDC_PRESS_BLD_ART_ABP_SYS^MDC|1.1.1.1.2|119|266016\^MDC_DIM_MMHG^MDC|90-110||||R
 ====
@@ -1167,7 +1167,7 @@ pm:AlertConditionDescriptor
 
 [NOTE]
 ====
-If a <<acronym_sdc>> ALERT CONDITION represents an avisory signal, the alert priority is set to *"None"* for this <<acronym_sdc>> ALERT CONDITION, and therefore, mapped to *"PN"* in the IHE ACM Alert Priority OBX segment.
+If a <<acronym_sdc>> ALERT CONDITION represents an advisory signal, the alert priority is set to *"None"* for this <<acronym_sdc>> ALERT CONDITION, and therefore, mapped to *"PN"* in the IHE ACM Alert Priority OBX segment.
 ====
 
 ====== Alert Type OBX Segment

diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc
@@ -240,7 +240,7 @@ When there are further updates of the weight value after the association of the
 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.
+The HL7 Observation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields.
 
 ====== OBR-2 Placer Order Number
 
@@ -655,7 +655,7 @@ For each numeric metric, a <<actor_somds_dec_gateway>> shall set the OBX-6 field
 ====
 NOTE: <<ref_tbl_dec_obx6_mapping>> defines the mapping of the SDC measurement unit to the data fields of the HL7 data type *CWE* used in the OBX-6 field.
 
-NOTE: For a device-releted element such as MDS, VMD, CHANNEL, or other metric types, the OBX-6 field is left empty.
+NOTE: For a device-related element such as MDS, VMD, CHANNEL, or other metric types, the OBX-6 field is left empty.
 ====
 ****
 
@@ -881,7 +881,7 @@ NOTE: If *pm:BodySite* element list contains more than one *pm:BodySite* element
 
 NOTE: <<ref_tbl_dec_obx20_mapping>> defines the mapping of the SDC body site element to the data fields of the HL7 data type *CWE* used in the OBX-20 field.
 
-NOTE: For a device-releted element such as MDS, VMD, or CHANNEL, the OBX-20 field is left empty.
+NOTE: For a device-related element such as MDS, VMD, or CHANNEL, the OBX-20 field is left empty.
 ====
 ****
 

diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc
@@ -26,7 +26,7 @@ If <<r8102>> is met, then a <<actor_somds_dec_gateway>> / <<actor_somds_acm_gate
 .Notes
 [%collapsible]
 ====
-NOTE: The PID-3 is a list of patient identifiers (e.g., medical record number, socal security number, visit number, account number, etc.)
+NOTE: The PID-3 is a list of patient identifiers (e.g., medical record number, social security number, visit number, account number, etc.)
 
 NOTE: <<ref_tbl_pid3_mapping>> defines the mapping of the <<acronym_mdib>> patient identification to the data fields of the HL7 data type *CX* used in the PID-3 field.
 
@@ -42,7 +42,7 @@ NOTE: If the <<acronym_mdib>> patient identification element *pm:PatientContextS
 |PID-3/CX-1
 |ID Number
 |pm:PatientContextState+++<wbr/>+++/pm:Identification+++<wbr/>+++/@Extension
-|The @Extension attribute contains the unique patient identifer.
+|The @Extension attribute contains the unique patient identifier.
 
 *Note that the field may contain a null value indicating that the identifier is missing.*
 

diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc
@@ -131,7 +131,7 @@ NOTE: A visit identifier could be a visit number, an account number, or any othe
 |/@Root
 |The @Root contains the unique identification of the HDO.
 
-*Note that if the HDO identifer is not defined the CX-4 field is required to be left empty.*
+*Note that if the HDO identifier is not defined the CX-4 field is required to be left empty.*
 
 |PV1-19/CX-5
 |Identifier Type Code

diff --git a/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc b/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc
@@ -176,7 +176,7 @@ Once the enterprise OID is registered, it is up to the medical device vendor to
 * 1.3.6.1.4.1.12345.*<Namespace>*.*<Type>*.*<Version>*: it is highly recommended to define the version number as the last child node in the OID. Different versions indicate a major (maybe breaking) change to the *Type* defined by the parent node.
 ====
 
-In the example above, the OID "_1.3.6.1.4.1.12345.2.1.1_" would represent a *private coding system* identifier in version *1* issued by the the *ventilation* business group of the *Medical Device XYZ Ltd.* company.
+In the example above, the OID "_1.3.6.1.4.1.12345.2.1.1_" would represent a *private coding system* identifier in version *1* issued by the *ventilation* business group of the *Medical Device XYZ Ltd.* company.
 
 .R0702
 [sdpi_requirement#r0702,sdpi_req_level=shall]
@@ -275,4 +275,4 @@ include::biceps-extension-provisions/tf3-ch-8.3.2.9.6-extension-equipment-identi
 include::biceps-content-module/tf3-ch-8.3.2.9.7-compound-metric-modelling.adoc[]
 
 // 8.3.2.10
-include::mdib-efficieny/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc[]
+include::mdib-efficiency/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc[]
diff --git a/asciidoc/volume3/tf3-main.adoc b/asciidoc/volume3/tf3-main.adoc
@@ -83,7 +83,7 @@ a| *{supplement_note}*: The content in the IHE PCD 2019 TF-3 3.1 Section will ne
 | Move IHE PCD 2019 TF-3 sections 3.2 to 3.7 to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.3.1.2 TO 8.3.1..7
 
 A new 8.3.1.1 Section should be added to the Classic DIM content section that addresses basic reporting.
-This content would be extracted from the existing (2019) Section 3.1, where that content is specific to the Classi DIM (see related note above).
+This content would be extracted from the existing (2019) Section 3.1, where that content is specific to the Classic DIM (see related note above).
 |===
 
 // 8.3.2