Corrected reference to BICEPS (from “10207-2017” to “10207-2017/Cor1-… (#557)

* Corrected reference to BICEPS (from “10207-2017” to “10207-2017/Cor1-2025”) and all its quotes

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

* Update asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc

* Update asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc

* Updated file name and title of BICEP ICS file

* Updated changelog for issue 485 (plus a few editorials on other issues)

* Deprecated requirements R1007, R1008, R1009, R1011, R0503, R0504, R0505, R0506, R0507, R0508, R1012 and R1013

* Fix invalid deprecated requirement reference in dev-33

* Removed note from R7002 and clarification sentence from 2:3.30.4.2.2

* Extended “3:8.3.2.10 BICEPS Extension Model”, first bullet point "IEEE 11073-10207 Clause 8, especially R0109,” to also refer to new BICEPS R0200, R0203 and R0204

* In “1:B.2.3.3 Service Consumer”, removed note (due to removal of BICEPS R0115)

* Updated 3:A.1 Coded Attribute XML Schema to rephrase documenation statement (aligning it with (in line with new BICEPS R0236)

* In “3:8.3.2.10.10.1 Model”, removed "DateAndTime" from the MDIB in Example 14 as well as in explanatory text above

* Added note to 10207 corrigendum (Basically: not standalone, must be used in conjuction with the version it corrects)

* attempt to correct build error due to reference note

* Fix bibliography list break by using list continuation for NOTE block

* Reversed deprecation of R1007 in line with discussion in issue

* Housekeeping: added deprecation tag to earlier-deprecated DEV-34

* Fix build failure: remove DeprecateTransaction from registered DEV-34 transaction

* Corrected R0613 and R0614 to intended "MdsState" (& hence making it compatible with new BICEPS R0200)

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

Author: JavierEspina

CHANGELOG.md

@@ -18,12 +18,12 @@ Each section shall contain a list of action items of the following format: `<bri
 
 ### Added
 
-- History Service design, MDPWS requirements and transactions ([#360](https://github.com/IHE/DEV.SDPi/issues/360))
+- History Service design, MDPWS requirements and transaction DEV-32 ([#360](https://github.com/IHE/DEV.SDPi/issues/360))
 - Clarification on SDPi-P safety requirements and considerations to explicitly include the application of the IEEE 11073-10700 standard ([#529](https://github.com/IHE/DEV.SDPi/issues/529))
 - Clarification on the use of `wsa:To` in greeting {`Hello`, `Bye`} notifications sent by a discovery proxy to a consumer ([#534](https://github.com/IHE/DEV.SDPi/issues/534))
 - Required SDPi-P actor grouping entries for BICEPS Content Creator and BICEPS Content Consumer in TF-1:10.3 ([#476](https://github.com/IHE/DEV.SDPi/issues/476))
-- Support semantic markup for deprecating requirements, transactions, use-cases, profiles, content modules and actors ([#511](https://github.com/IHE/DEV.SDPi/issues/511)).
-- Clarify expected behaviour and requirements for consumers making multiple concurrent connections to providers ([#503](https://github.com/IHE/DEV.SDPi/issues/503)).
+- Support for semantic markup for deprecating requirements, transactions, use-cases, profiles, content modules and actors ([#511](https://github.com/IHE/DEV.SDPi/issues/511))
+- Clarification on expected behaviour and requirements for consumers making multiple concurrent connections to providers ([#503](https://github.com/IHE/DEV.SDPi/issues/503))
 
 ### Changes
 
@@ -35,6 +35,7 @@ Each section shall contain a list of action items of the following format: `<bri
 - Updated actor grouping tables for SDPi-R, -A and -xC profiles for consistency and template compliance ([#544](https://github.com/IHE/DEV.SDPi/issues/544))
 - History Service XML Schema: remove hm:ChangeSequence element from root level; use element type over element ref ([#297](https://github.com/IHE/DEV.SDPi/issues/548))
 - History Service XML Schema: rename HistoryReportType to HistoricReportChoiceType ([#297](https://github.com/IHE/DEV.SDPi/issues/548))
+- Updates required to incorporate changes of BICEPS (IEEE 11073-10207) standard through its 2025 Corrigendum ([#485](https://github.com/IHE/DEV.SDPi/issues/485))
 - Updated SDPi-P Actors and Options Tables to include the new History Service option ([#561](https://github.com/IHE/DEV.SDPi/issues/561))
 
 ### Editorial Fixes

articles/sdpi-article-ihe-tf-asciidoc-cookbook.adoc

@@ -895,7 +895,7 @@ The example below illustrates the AsciiDoc source required to define a content m
 [#vol3_clause_sdc_biceps_semantic_content_module,role="content-module", content-module-id="biceps",oid-arcs=".1,.1.1"]
 ===== SDC/BICEPS Content Module
 
-The biceps standard, <<ref_ieee_11073_10207_2017>>, provides an extensive semantic...
+The biceps standard, <<ref_ieee_11073_10207_2017_Cor1_2025>>, provides an extensive semantic...
 ----
 
 Attaching the `content-module` role to a section marks it as a [content module](https://profiles.ihe.net/DEV/SDPi/index.html#vol3). A (document-unique) identifier must be defined in the `content-module-id` attribute. The section title is used for the content module label. An <<defining-oids,object identifier (oid)>> is required for each content module. Typical a content module gets a version neutral oid (e.g., `.1`) and a versioned oid (e.g., `.1.1`). 

asciidoc/listings/vol3-clause-biceps-content-example-timestamp-version.xml

@@ -39,7 +39,7 @@
             </pm:Mds>
         </pm:MdDescription>
         <pm:MdState>
-          <pm:State ActivationState="StndBy" LastSet="1733317200000" DateAndTime="1733328000000"
+          <pm:State ActivationState="StndBy" LastSet="1733317200000"
                     DescriptorHandle="clk" StateVersion="15" RemoteSync="1" 
                     xsi:type="pm:ClockState">
             <ext:Extension>

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

@@ -38,7 +38,7 @@
 | General reference to the abstract, implementation technology independent SDC components defined in the IEEE 11073-10207 standard.
 |
 | [[acronym_biceps,BICEPS]] BICEPS
-| <<ref_ieee_11073_10207_2017>>
+| <<ref_ieee_11073_10207_2017_Cor1_2025>>
 | SDC
 
 | [[term_central_station,Central Station]] Central Station
@@ -201,7 +201,7 @@
 | Structured collection of any data objects that are provided by a <<vol1_spec_sdpi_p_actor_somds_provider>> or <<actor_biceps_content_creator>>, including both descriptive and state information.
 |
 | [[acronym_mdib,MDIB]] MDIB
-| <<ref_ieee_11073_10207_2017>>
+| <<ref_ieee_11073_10207_2017_Cor1_2025>>
 | SDC
 
 | [[term_mdib_configuration, MDIB Configuration]] MDIB Configuration
@@ -250,7 +250,7 @@
 | A core object type in the IEEE 11073 device communication standards.  It represents the top-level containment of the hierarchy of information objects contained in a device.
 |
 | [[acronym_mds,MDS]] MDS
-| <<ref_ieee_11073_10207_2017>>, <<ref_ieee_11073_10201_2004>>
+| <<ref_ieee_11073_10207_2017_Cor1_2025>>, <<ref_ieee_11073_10201_2004>>
 |
 
 | [[term_model_based_systems_engineering,Model-Based Systems Engineering (MBSE)]] Model-Based Systems Engineering
@@ -408,7 +408,7 @@ elements, from requirements to system components to Verification & Validation te
 implements a service-oriented <<acronym_sdc>> architecture composed of service providers and service consumers.
 |
 | [[acronym_somds,SOMDS]] SOMDS
-| <<ref_ieee_11073_10207_2017>>
+| <<ref_ieee_11073_10207_2017_Cor1_2025>>
 | SDC
 
 | [[term_slewing_adjustments,slewing time adjustments]] Slewing time adjustments
@@ -506,7 +506,7 @@ implements a service-oriented <<acronym_sdc>> architecture composed of service p
 | A core object type in the IEEE 11073 device communication standards. It represents the second-level containment of the hierarchy of information objects contained in a device.
 |
 | [[acronym_vmd,VMD]] VMD
-| <<ref_ieee_11073_10207_2017>>, <<ref_ieee_11073_10201_2004>>
+| <<ref_ieee_11073_10207_2017_Cor1_2025>>, <<ref_ieee_11073_10201_2004>>
 |
 
 |===

…nce-statement-ieee-11073-10207-2017.adoc …ent-ieee-11073-10207-2017-Cor1-2025.adocasciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc renamed to asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017-Cor1-2025.adoc asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc renamed to asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017-Cor1-2025.adoc

@@ -1,6 +1,6 @@
-// Standard Conformance Statement:  IEEE 11073-10207:2017
+// Standard Conformance Statement:  IEEE 11073-10207:2025
 
-==== ISO/IEC 11073-10207 BICEPS ICS Tables
+==== ISO/IEC 11073-10207/Cor1-2025 BICEPS ICS Tables
 
 [%noheader]
 [%autowidth]
@@ -12,7 +12,7 @@ Requirement Definition (this table's rows) will be referenced where they are sat
 
 |===
 
-*Standard Version:*  IEEE 11073-10207:2017
+*Standard Version:*  IEEE 11073-10207:2025
 
 ===== General
 
@@ -28,8 +28,6 @@ ADD IEEE:  *Service Provider ICS table here*
 
 ===== Service Consumer
 
-NOTE:  CONS-1 is broken; R0115 is not optional in the released document.
-
 ADD IEEE:  *Service Consumer ICS table here*
 
 ===== Remote Control
@@ -47,4 +45,3 @@ A future version of SDPi will describe how to cope with contexts, with device co
 |===
 
 ADD IEEE:  *Context Processing ICS table here*
-

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

@@ -159,7 +159,7 @@ include::../plantuml/vol1-figure-sdpi-p-example-sequence-diagram.puml[]
 [#vol1_spec_sdpi_p_actor_somds_participant, reftext='SOMDS Participant',role="actor-alias",actor-id="somds_participant"]
 Actor Summary Definition:
 [none]
-. A foundational abstract actor that provides the SOA architectural constructs for interoperating in a Service-Oriented Medical Device System (SOMDS) network instance, including information, messaging and dynamic behavior models.   (See <<ref_ieee_11073_10207_2017>>  “PARTICIPANT” definition)
+. A foundational abstract actor that provides the SOA architectural constructs for interoperating in a Service-Oriented Medical Device System (SOMDS) network instance, including information, messaging and dynamic behavior models.   (See <<ref_ieee_11073_10207_2017_Cor1_2025>>  “PARTICIPANT” definition)
 
 All systems participating in a SOMDS network instance must implement this Abstract actor.
 
@@ -178,7 +178,7 @@ See <<vol1_clause_appendix_a_requirements_from_narratives_to_pnt_interfaces>> fo
 [#vol1_spec_sdpi_p_actor_somds_provider, reftext='SOMDS Provider',role="actor-alias",actor-id="somds_provider"]
 Actor Summary Definition:
 [none]
-. A <<vol1_spec_sdpi_p_actor_somds_participant>> that provides at least one service to the other participant systems.  (See <<ref_ieee_11073_10207_2017>>  “SERVICE PROVIDER” definition.)
+. A <<vol1_spec_sdpi_p_actor_somds_participant>> that provides at least one service to the other participant systems.  (See <<ref_ieee_11073_10207_2017_Cor1_2025>>  “SERVICE PROVIDER” definition.)
 
 Every <<vol1_spec_sdpi_p_actor_somds_provider>> is paired with (inherits from) the abstract _<<vol1_spec_sdpi_p_actor_somds_participant>>_ Actor.
 
@@ -189,7 +189,7 @@ A system that participates in a SOMDS network instance can include both <<vol1_s
 [#vol1_spec_sdpi_p_actor_somds_consumer, reftext='SOMDS Consumer',role=actor-alias,actor-id="somds_consumer"]
 Actor Summary Definition:
 [none]
-. A <<vol1_spec_sdpi_p_actor_somds_participant>> that discovers and utilizes at least one service, functional capability, exposed to a network communications backbone by a <<vol1_spec_sdpi_p_actor_somds_provider>>. (See <<ref_ieee_11073_10207_2017>>  “SERVICE CONSUMER” and “SERVICE” definitions.)
+. A <<vol1_spec_sdpi_p_actor_somds_participant>> that discovers and utilizes at least one service, functional capability, exposed to a network communications backbone by a <<vol1_spec_sdpi_p_actor_somds_provider>>. (See <<ref_ieee_11073_10207_2017_Cor1_2025>>  “SERVICE CONSUMER” and “SERVICE” definitions.)
 
 Every <<vol1_spec_sdpi_p_actor_somds_consumer>> is paired with (inherits from) the abstract _<<vol1_spec_sdpi_p_actor_somds_participant>>_ Actor.
 
@@ -326,7 +326,7 @@ See <<vol1_clause_smart_app_platforms>> for additional discussion.
 [#vol1_spec_sdpi_p_actor_biceps_content_creator, reftext='BICEPS Content Creator',role=actor-alias,actor-id="biceps_content_creator"]
 Actor Summary Definition:
 [none]
-. Provides <<acronym_mdib>> content conformant to <<ref_ieee_11073_10207_2017>> BICEPS specification and for consumption by other <<vol1_spec_sdpi_p_actor_biceps_content_consumer>> systems.
+. Provides <<acronym_mdib>> content conformant to <<ref_ieee_11073_10207_2017_Cor1_2025>> BICEPS specification and for consumption by other <<vol1_spec_sdpi_p_actor_biceps_content_consumer>> systems.
 
 All content created and provided by a <<vol1_spec_sdpi_p_actor_biceps_content_creator>> shall be conformant to the BICEPS content module specifications in <<vol3_clause_sdc_biceps_semantic_content_module>> and related sections.
 
@@ -350,7 +350,7 @@ sdpi_include_content_module::dialysis[actor-id="biceps_content_creator",support=
 [#vol1_spec_sdpi_p_actor_biceps_content_consumer, reftext='BICEPS Content Consumer',role=actor-alias,actor-id="biceps_content_consumer"]
 Actor Summary Definition:
 [none]
-. Processes <<acronym_mdib>> information conformant to <<ref_ieee_11073_10207_2017>> BICEPS specifications provided by <<vol1_spec_sdpi_p_actor_biceps_content_creator>> systems.
+. Processes <<acronym_mdib>> information conformant to <<ref_ieee_11073_10207_2017_Cor1_2025>> BICEPS specifications provided by <<vol1_spec_sdpi_p_actor_biceps_content_creator>> systems.
 
 A <<vol1_spec_sdpi_p_actor_biceps_content_consumer>> shall be capable of processing information provided by a <<actor_biceps_content_creator>>, in accordance to the BICEPS content module specifications in <<vol3_clause_sdc_biceps_semantic_content_module>> and related sections.
 

asciidoc/volume1/tf1-ch-11-sdpi-r.adoc

@@ -108,7 +108,7 @@ Actor Summary Definition:
 [none]
 . A <<vol1_spec_sdpi_p_actor_somds_provider>> grouped actor that sends medical data to a <<vol1_spec_sdpi_p_actor_somds_consumer>>.
 
-This actor is designed to process information with an _intended medical purpose_, and thus will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards (<<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>).
+This actor is designed to process information with an _intended medical purpose_, and thus will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017_Cor1_2025>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards (<<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>).
 
 Every <<vol1_spec_sdpi_r_actor_somds_medical_data_provider>> is grouped with an <<vol1_spec_sdpi_p_actor_somds_provider>> to enable <<acronym_somds>>-based connectivity.
 This actor inherits all the capabilities of the paired <<vol1_spec_sdpi_p_actor_somds_provider>>.
@@ -124,7 +124,7 @@ Actor Summary Definition:
 [none]
 . A <<vol1_spec_sdpi_p_actor_somds_consumer>> grouped actor that receives medical data from a <<vol1_spec_sdpi_p_actor_somds_provider>>.
 
-This actor is designed to process information with an _intended medical purpose_, and thus will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards (<<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>).
+This actor is designed to process information with an _intended medical purpose_, and thus will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017_Cor1_2025>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards (<<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>).
 
 Every <<vol1_spec_sdpi_r_actor_somds_medical_data_consumer>> is grouped with an <<vol1_spec_sdpi_p_actor_somds_consumer>> to enable <<acronym_somds>>-based connectivity.
 This actor inherits all the capabilities of the paired <<vol1_spec_sdpi_p_actor_somds_consumer>>.
@@ -140,7 +140,7 @@ Actor Summary Definition:
 [none]
 . A <<vol1_spec_sdpi_p_actor_somds_v2_gateway>> grouped actor that supports the bi-directional exchange of medical data using IHE Device Enterprise Communication (DEC) messages with non-SOMDS systems and applications.
 
-This actor is designed to process information with an _intended medical purpose_, and thus will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards (<<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>).
+This actor is designed to process information with an _intended medical purpose_, and thus will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017_Cor1_2025>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards (<<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>).
 
 Every <<vol1_spec_sdpi_r_actor_somds_dec_gateway>> is grouped with an <<vol1_spec_sdpi_p_actor_somds_v2_gateway>> to enable <<acronym_somds>>-based connectivity.
 This actor inherits all the capabilities of the paired <<vol1_spec_sdpi_p_actor_somds_v2_gateway>>.

asciidoc/volume1/tf1-ch-12-sdpi-a.adoc

@@ -127,7 +127,7 @@ Actor Summary Definition:
 This actor is designed to publish medical device alert information to a <<vol1_spec_sdpi_a_actor_somds_medical_alert_consumer>>, which in turn can communicate it safely and reliably to a clinician.
 Transactions enabled for this actor are identified in <<vol1_table_sdpi_a_actors_transactions>> above.
 
-Given this _intended medical purpose_, the actor will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10702_202x>> (Alert <<acronym_pkp>>).
+Given this _intended medical purpose_, the actor will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017_Cor1_2025>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10702_202x>> (Alert <<acronym_pkp>>).
 
 Every <<vol1_spec_sdpi_a_actor_somds_medical_alert_provider>> is grouped with an <<vol1_spec_sdpi_p_actor_somds_provider>> to enable <<acronym_somds>>-based connectivity.
 This actor inherits all the capabilities of the paired <<vol1_spec_sdpi_p_actor_somds_provider>>.
@@ -146,7 +146,7 @@ Actor Summary Definition:
 This actor is designed to receive and manage medical device alert information to communicate it safely and reliably to a clinician.
 Transactions enabled for this actor are identified in <<vol1_table_sdpi_a_actors_transactions>> above.
 
-Given this _intended medical purpose_, the actor will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10702_202x>> (Alert <<acronym_pkp>>).
+Given this _intended medical purpose_, the actor will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017_Cor1_2025>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10702_202x>> (Alert <<acronym_pkp>>).
 
 Every <<vol1_spec_sdpi_a_actor_somds_medical_alert_consumer>> is grouped with an <<vol1_spec_sdpi_p_actor_somds_consumer>> to enable <<acronym_somds>>-based connectivity.
 This actor inherits all the capabilities of the paired <<vol1_spec_sdpi_p_actor_somds_consumer>>.
@@ -170,7 +170,7 @@ Note that optional capabilities for this specification, as specified in <<vol1_c
 
 Transactions enabled for this actor are identified in <<vol1_table_sdpi_a_actors_transactions>> above.
 
-Given this _intended medical purpose_, the actor will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10702_202x>> (Alert <<acronym_pkp>>).
+Given this _intended medical purpose_, the actor will fully address applicable requirements from the core <<acronym_sdc>> standards (<<ref_ieee_11073_10207_2017_Cor1_2025>> and <<ref_ieee_11073_20701_2018>>), as well as the <<acronym_pkp>> standards <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10702_202x>> (Alert <<acronym_pkp>>).
 
 This actor shall implement the <<vol1_spec_sdpi_a_actor_somds_medical_alert_consumer>> capabilities, receiving alert information provided by <<vol1_spec_sdpi_a_actor_somds_medical_alert_provider>> systems and publishing them as [DEV-04] / [PCD-04] Transactions to external ACM Alert Manager (AM) systems.
 If <<vol1_clause_sdpi_a_actor_option_remote_alert_signaling_reftext>> is implemented, then this actor will also support the <<vol1_spec_sdpi_a_actor_somds_medical_alert_provider>> capabilities, receiving [DEV-04] / [PCD-04] Transactions from external ACM Device Observation Reporter (DOR) systems and making them available to other <<vol1_spec_sdpi_a_actor_somds_medical_alert_consumer>> systems.