From 0f7e5ca206323ea588794059f744c6b6726cddf6 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 6 May 2026 11:41:15 -0500 Subject: [PATCH 1/4] punctuation updates --- asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc b/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc index 88e5b006..a806f868 100644 --- a/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc +++ b/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc @@ -161,13 +161,13 @@ The <> Base Requirements for Participants in a Servic NOTE: This implies that a MANUFACTURER that needs to use private codes has to keep a private coding system for these codes. Following the concept of private codes that is defined in <>, a MANUFACTURER introduces and maintains a set of codes that adhere to the principles of the <> nomenclature standards. -There are different ways to define a globally unique identifier for the vendor-specific private coding system (e. g. URL, OID, etc.). In the context of medical device interoperability, the recommendation is to use an "object identifier" (OID) for private codes as detailed in <> and other purposes (e. g. private SDC extensions): +There are different ways to define a globally unique identifier for the vendor-specific private coding system (e.g., URL, OID, etc.). In the context of medical device interoperability, the recommendation is to use an "object identifier" (OID) for private codes as detailed in <> and other purposes (e.g., private SDC extensions): -* Compared with other identifiers (e.g. URLs) OIDs are very compact, which helps to keep the size of data messages low +* Compared with other identifiers (e.g., URLs) OIDs are very compact, which helps to keep the size of data messages low * It is free of charge to register a globally unique enterprise OID with https://www.iana.org/assignments/enterprise-numbers/assignment/apply/[IANA]. -An enterprise OID assigned by IANA always starts with the prefix *iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)*. The actual enterprise node number, which follows the prefix, is globally unique to the medical device vendor (e. g. "_1.3.6.1.4.1.12345_" for the *Medical Device XYZ Ltd.* company). +An enterprise OID assigned by IANA always starts with the prefix *iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)*. The actual enterprise node number, which follows the prefix, is globally unique to the medical device vendor (e.g., "_1.3.6.1.4.1.12345_" for the *Medical Device XYZ Ltd.* company). Once the enterprise OID is registered, it is up to the medical device vendor to extend the OID by adding child nodes. The child nodes don't have a globally unique meaning, but the enterprise OID plus the child nodes are required to be globally unique. It is recommended to define a child node schema, and assign unique numbers to the concepts on each node level. From fe639ad3f87e0f5f110d9ee4e665bf4c397bb9c5 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 6 May 2026 11:56:00 -0500 Subject: [PATCH 2/4] punctuation update --- .../tf3-ch-8.3.2.9.1-extension-constraints.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc index ed84c6c9..cd3e114a 100644 --- a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc +++ b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc @@ -22,7 +22,7 @@ Some XML processor APIs do not support ordered access to XML _mixed content_, wh ---- -There are APIs that do not fully implement the XML Document Object Model and hence cannot individually access text nodes (e.g. as in <>: "Here", "is some", "interlaced", and "text") in between the interlaced elements but only as concatenated text. +There are APIs that do not fully implement the XML Document Object Model and hence cannot individually access text nodes (e.g., as in <>: "Here", "is some", "interlaced", and "text") in between the interlaced elements but only as concatenated text. This makes verification measures unnecessarily complicated. As mixed content is not required to be available in device to device communication, <> prohibits the use of mixed content types in BICEPS extensions. From e83052030406dc11e5ade563cb0852d3fafe3d62 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 6 May 2026 11:58:50 -0500 Subject: [PATCH 3/4] punctuation update --- asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc b/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc index 55e9ce8f..993d6915 100644 --- a/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc +++ b/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc @@ -40,7 +40,7 @@ If the metric *@Value* falls in one of the *pm:TechnicalRange* elements and in o *For Metric @Samples*: -For metric *@Samples*, it is possible that individual samples fall in different *pm:TechnicalRange* or *pm:PhysiologicalRange* elements. In this case the <> has to decide which of the *pm:TechnicalRange* or *pm:PhysiologicalRange* element is considered as the _active range_ (*pm:Range* element) for the entire set of samples currently utilized for displaying - e.g. *Airway Pressure* wave displayed with the highest precision defined by the _active range_ at the consumer's screen. +For metric *@Samples*, it is possible that individual samples fall in different *pm:TechnicalRange* or *pm:PhysiologicalRange* elements. In this case the <> has to decide which of the *pm:TechnicalRange* or *pm:PhysiologicalRange* element is considered as the _active range_ (*pm:Range* element) for the entire set of samples currently utilized for displaying - e.g., *Airway Pressure* wave displayed with the highest precision defined by the _active range_ at the consumer's screen. If an individual sample falls in one of the *pm:TechnicalRange* elements and in one of *pm:PhysiologicalRange* elements at the same time, the *pm:PhysiologicalRange* element of the metric state will supersede the *pm:TechnicalRange* element of the descriptor and will become the _active range_ for this particular sample. From b35e977c7043e7feab4bf8372570a222a59c6deb Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Wed, 6 May 2026 19:31:01 +0200 Subject: [PATCH 4/4] Update CHANGELOG for version 2.4.1 Add editorial fixes for SDPi 2.4 publication. --- CHANGELOG.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 3da5a619..5f6dbde6 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,12 @@ Each section shall contain a list of action items of the following format: ` +## [2.4.1] - 2026-05-07 + +### Editorial Fixes + +- IHE Publications changes for SDPi 2.4 publication ("e.g., " punctuation) ([PR#526](https://github.com/IHE/DEV.SDPi/pull/526)) + ## [2.4.0] - 2026-04-01 ### Added