Merge remote-tracking branch 'origin/master'

CHANGELOG.md

@@ -15,6 +15,38 @@ Each section shall contain a list of action items of the following format: `<bri
 
 ## [Unreleased]
 
+### Changes
+- Fixed action URN in waveform stream example ([#292](https://github.com/IHE/DEV.SDPi/issues/292))
+- Clarified intentionality of difference between ad-hoc and managed discovery ([#317](https://github.com/IHE/DEV.SDPi/issues/317))
+- Clarified FHIR Gateway support for multiple paradigms ([#264](https://github.com/IHE/DEV.SDPi/issues/264))
+- Clarified that the SES sections are not comprehensive for risk management ([#271](https://github.com/IHE/DEV.SDPi/issues/271))
+- Bibliography note added indicating the rationale for the subcategories ([#266](https://github.com/IHE/DEV.SDPi/issues/266))
+- SDPi Use Case Approach explanatory text added to start of supplement ([#263](https://github.com/IHE/DEV.SDPi/issues/263))
+
+- Enhanced explanation of SOA aspects of the SDC/SDPi specification (HL7 Ballot) ([#276](https://github.com/IHE/DEV.SDPi/issues/276))
+
+### Editorial Fixes
+- Added deprecation notice for three requirements due to expected impact of BICEPS standard corrigendum ([#334](https://github.com/IHE/DEV.SDPi/issues/334))
+- Updated SDPi "Topic of Interest" issue management for clarity ([#274](https://github.com/IHE/DEV.SDPi/issues/274))
+- Addressed three JIRA tickets listed in issue ([#275](https://github.com/IHE/DEV.SDPi/issues/275))
+- Corrected some entries in "1:B.1 Referenced Standards" for consistency ([#267](https://github.com/IHE/DEV.SDPi/issues/267))
+- Commented out concept sections 1:10.4.1.3 thru 1:10.4.1.10 and minimized referencing to years for improving readability ([#268](https://github.com/IHE/DEV.SDPi/issues/268))
+- Removed TBD statements from Table A-1 ([#273](https://github.com/IHE/DEV.SDPi/issues/273))
+- Updated per IHE Style Conventions for numbers-in-text, em dashes, punctuation marks, etc. ([#269](https://github.com/IHE/DEV.SDPi/issues/269))
+
+### Added
+- Added SDPi FHIR Gateway ([#252](https://github.com/IHE/DEV.SDPi/issues/252))
+
+## [1.4.1] - 2024-10-04
+
+### Editorial Fixes
+
+- IHE Publications Editor review corrections - typos and style corrections ([#319](https://github.com/IHE/DEV.SDPi/pull/319))
+- Unclarities and typos in TF-1:A.1 ([#316](https://github.com/IHE/DEV.SDPi/issues/316))
+
+### Added
+- No additions
+
 ## [1.4.0] - 2024-09-17
 
 ### Editorial Fixes

asciidoc/listings/vol2-clause-appendix-a-mdpws-dev-29-waveformstream.xml

@@ -4,7 +4,7 @@
         xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
         xmlns:wsa="http://www.w3.org/2005/08/addressing">
     <s12:Header>
-        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/WaveformStream</wsa:Action>
+        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/WaveformService/WaveformStream</wsa:Action>
         <wsa:MessageID><!-- ... --></wsa:MessageID>
         <wsa:To><!-- ... --></wsa:To>
     </s12:Header>

asciidoc/sdpi-supplement-intro.adoc

@@ -21,14 +21,14 @@ For HL7 ballot comment resolution, links are made from HL7 ballot Jira tickets t
 
 
 NOTE: This supplement also includes both normative and informative references to other specifications (see <<vol1_appendix_b_references>>), some of which are finalized and published and others that are either being developed or in revision.
-For example, the IEEE 11073-10702 PKP standard is in development with balloting expected late 2024 and publication mid-2025; however, some requirements from that pre-standard may be included in this SDPi specification, providing a pathway to early experience and validation.
+For example, the IEEE 11073-10702 PKP standard is in mature development stage; however, some requirements from that pre-standard may be included in this SDPi specification, providing a pathway to early experience and validation.
 When a referenced specification is used that is in development or revision, a note will be provided in the <<vol1_appendix_b_referenced_standards>> clearly indicating its status.
 
 It is recognized that this release is a work-in-progress that will continue to subsequent versions.
 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,18 +47,18 @@ 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*
 
-* General overview of the SDPi architectural approach & integrated set of profiles
+* General overview of the SDPi architectural approach and integrated set of profiles
 * Profile-specific sections
 * Related appendices, for example the integration of this family of SDPi Profiles with other sources of requirements - use cases or reference standards
 
@@ -71,6 +71,18 @@ To that end, the supplement includes updates to all (3) IHE DEV TF volumes, incl
 
 * New content covering the application of ISO/IEEE 11073 SDC semantic standards to device content modules, with a primary focus on specifications related to the ISO/IEEE 11073-10207 BICEPS standard.
 
+[#supplement_clause_mapping_clinical_scenarios_to_profile_requirements]
+=== Use Cases:  Mapping Clinical Scenarios to Profile Requirements
+IHE technical framework integration profile specifications include use case sections to ensure that the technical solutions are rooted in real-world application requirements.
+These sections typically include a basic description of use case scenarios, identify the key systems that exchange information, application-level detail of the information exchanged, and perhaps even some sequence diagrams.
+This information may also be used to drive the test cases that are used for conformity assessment, ensuring that the resulting specification implementation meets the intended needs.
+
+This supplement includes this same organization; however, it also defines a set of general, non-profile-specific clinical use cases that provide requirements, which may be mapped to multiple SDPi integration profiles.
+Section <<vol1_appendix_c_dpi_use_cases>> provides a collection of these high-level clinical use cases.
+
+FOR READERS OF THIS SUPPLEMENT, a good strategy might be to first review the use cases in the Volume 1 appendix (e.g., <<vol1_clause_appendix_c_use_case_sicdmp>> ), and then review the specific profiles to which the clinical scenario requiremets have been mapped.
+Reviewing the use case specifications in this order will provide the needed context to understand what is presented in each profile.
+
 [#supplement_clause_joint_ihe_hl7_gemini_ses_mdi_project_development]
 === Joint IHE-HL7 Gemini SES+MDI Project Development
 This supplement is the result of a joint https://confluence.hl7.org/x/Xzf9Aw[IHE-HL7 Gemini Device Interoperability program] which began early 2020.
@@ -96,7 +108,7 @@ These three objectives may be summarized as follows:
 [none]
 * *Requirements Interoperability (RI)*
 [none]
-** Ability to integrate & automate requirements and capabilities from component specifications & standards to enable traceability & coverage at <<term_conformity_assessment>> (<<acronym_ca>>) of the component product interface
+** Ability to integrate and automate requirements and capabilities from component specifications and standards to enable traceability and coverage at <<term_conformity_assessment>> (<<acronym_ca>>) of the component product interface
 * *Model Centric (MC)*
 [none]
 ** Transition from a document-centric to a _computable model-based "single source of truth"_ specification from which the Technical Framework becomes a view of the model
@@ -105,10 +117,10 @@ These three objectives may be summarized as follows:
 ** Enable CA test reports that are genuinely _"regulatory submission ready"_ (e.g., inclusion in a U.S. FDA 510(k) submission package)
 
 The SDPi {ihe_supplement_sdpi_revision} version of the supplement continues to make small but significant steps toward support of these objectives, especially Requirements Interoperability, as well as the use of AsciiDoc metadata to annotate the document sources for post-processing.
-Clearly, moving toward <<term_model_centric>> specifications and full integration of <<term_model_based_systems_engineering>> (<<acronym_mbse>>) will take considerable effort and time; however, this supplement represents a humble start in that direction.
+Clearly, moving toward <<term_model_centric>> specifications and full integration of <<term_model_based_systems_engineering>> will take considerable effort and time; however, this supplement represents a humble start in that direction.
 Subsequent supplement versions will build upon these objectives and support a new level of rigor for connectathon and product conformity assessment testing and ultimately test reports that directly impact the challenges around medical product regulatory submissions.
 
-Additional discussion is provided in <<vol1_appendix_a_requirements_management_for_p_n_t_interperability>>, and on the https://confluence.hl7.org/pages/viewpage.action?pageId=82906664#ConformityAssessment&Tooling-RI+MC+RRforMedTechSpecificationsInitiative[Gemini project's confluence pages].
+Additional discussion is provided in <<vol1_appendix_a_requirements_management_for_p_n_t_interperability>>, and on the https://confluence.hl7.org/pages/viewpage.action?pageId=82906664#ConformityAssessment&Tooling-RI+MC+RRforMedTechSpecificationsInitiative[Gemini project's Confluence pages].
 See also related discussions on the Gemini Project's https://confluence.hl7.org/x/XhPUB[Pathway to an Ecosystem of Plug-and-Trust Products].
 
 

asciidoc/sdpi-supplement-issues.adoc

@@ -7,12 +7,12 @@
 === SDPi "Topic of Interest" Issue Management
 
 All SDPi supplement issues are tracked in the https://github.com/IHE/DEV.SDPi/issues[IHE Github DEV.SDPi repository Issues section].
-Filter the issues on "Topic of Interest" to see a full list.  +
+Filter the issues on "Topic of Interest" to see a full list related to any "Topic of Interest".  +
 
-* To see the full list of OPEN issues, filter on: is:issue is:open label:"Topic of Interest"
-* To see the full list of CLOSED issues, filter on: is:issue is:closed label:"Topic of Interest"
+* To see the full list of OPEN issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen+label%3A%22Topic+of+Interest%22
+* To see the full list of CLOSED issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed+label%3A%22Topic+of+Interest%22
 
-For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#overview-from-discussion-to-planning-to-development[_Overview: From Discussion to Planning to Development_] and the confluence article https://confluence.hl7.org/pages/viewpage.action?pageId=82912211#TopicsofInterest-TopicResolutionWorkflow[_Topics of Interest -- Topic Resolution Workflow_].
+For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#overview-from-discussion-to-planning-to-development[_Overview: From Discussion to Planning to Development_] and the Confluence article https://confluence.hl7.org/pages/viewpage.action?pageId=82912211#TopicsofInterest-TopicResolutionWorkflow[_Topics of Interest -- Topic Resolution Workflow_].
 
 [sdpi_offset=clear]
 === Open Issues and Topic of Interests

asciidoc/sdpi-supplement.adoc

@@ -20,11 +20,11 @@
 :sdpi_milestone_publication: SDPi 1.4 Publication
 :sdpi_milestone_review: SDPi 1.4 Review
 
-:ihe_supplement_sdpi_revision: 1.4.0
+:ihe_supplement_sdpi_revision: 1.4.1
 :ihe_supplement_sdpi_revision_short: 1.4
 :ihe_supplement_sdpi_revision_date: {localdatetime}
 :ihe_supplement_sdpi_revision_label: Standard for Trial Use / Implementation
-:ihe_supplement_sdpi_publication_month: September 17, 2024
+:ihe_supplement_sdpi_publication_month: October 7, 2024
 :ihe_supplement_sdpi_public_comment_submission_deadline: N/A
 
 {empty} +

asciidoc/volume0/tf0-ch-a-actors.adoc

@@ -112,18 +112,14 @@ The table below lists _existing_ actors that are utilized in this specification.
 |===
 |Existing Actor Name |Definition
 
-|[[actor_alert_aggregator,Alert Aggregator]] Alert Aggregator  +
-*_(TBD) -- If the ACM Gateway uses this_*
-| This actor receives alerts from the Alert Reporter and collects status events related to the dissemination of the alert.
-
 |[[actor_alert_consumer,Alert Consumer]] Alert Consumer
 | The Alert Consumer (ACON) receives the alert from the Alert Reporter (AR) and uses the alert information strictly as a consumer of the alert being raised.  There is no implementation requirement for how the ACON ultimately uses the alert information.
 
 |[[actor_alert_manager,Alert Manager]] Alert Manager
 | The Alert Manager (AM) receives the alerts from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC), and optionally, provides the alert to the Alert Archiver (AA) or Alert Consumer (ACON) upon subscription.
 
 |[[actor_alert_reporter,Alert Reporter]] Alert Reporter
-| This actor originates the alert (an alarm, either physiological or technical, or an advisory). May also query the Alert Aggregator for the status of the alert.
+| This actor originates the alert (an alarm, either physiological or technical, or an advisory).
 
 |[[actor_device_observation_consumer,Device Observation Consumer]] Device Observation Consumer
 | The actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both.
@@ -132,8 +128,8 @@ The table below lists _existing_ actors that are utilized in this specification.
 | The Device Observation Reporter (DOR) receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics.
 
 
-| Time Client +
-*_(TBD -- Do dependent profile actors like CT TC get included in this table?)_*
+| Time Client
+
 | Establishes time synchronization with one or more Time Servers using the NTP protocol and either the NTP or SNTP algorithms.  Maintains the local computer system clock synchronization with UTC based on synchronization with the Time Servers.
 
 |===

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/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc

@@ -16,7 +16,7 @@ Requirement Definition (this table's rows) will be referenced where they are sat
 
 ===== General
 
-WARNING:  GEN-1 & GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions.
+WARNING:  GEN-1 and GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions.
 
 ADD IEEE:  *Table 20 -- General ICSs table here*