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 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. 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. 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.