Merge branch 'master' into 273-hl7-2024-jan-resolve-or-remove-tbd-sta…

…tements-from-text

CHANGELOG.md

@@ -18,12 +18,14 @@ Each section shall contain a list of action items of the following format: `<bri
 ### 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))
 
 ### 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))
 
 
 ## [1.4.1] - 2024-10-04

asciidoc/sdpi-supplement-intro.adoc

@@ -21,7 +21,7 @@ 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.

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

@@ -455,8 +455,10 @@ See related discussion at <<vol3_clause_biceps_mapping_using_somds_connector_con
 a| *{supplement_note}*: The TF-3 SDC/BICEPS Mapping of SOMDS Connector Content Modules section is out-of-scope., but included above for completeness of this actor overview.
 |===
 
-Although the SDPi-P Profile _<<vol1_spec_sdpi_p_actor_somds_connector>>_ provides for non-SOMDS _protocol-specific_ adaptors, they establish the foundation for specifying system and application-specific interfaces such as for EHR or decision support systems (e.g., sepsis determination). See <<vol1_clause_sdpi_p_ensuring_time_synchronization>>, and <<vol1_clause_sdpi_p_aggregators_proxies_sensors>> for additional perspectives and concepts on how SOMDS Connectors may be implemented.
-
+Although the SDPi-P Profile _<<vol1_spec_sdpi_p_actor_somds_connector>>_ provides for non-SOMDS _protocol-specific_ adaptors, they establish the foundation for specifying system and application-specific interfaces such as for EHR or decision support systems (e.g., sepsis determination).
+////
+See <<vol1_clause_sdpi_p_ensuring_time_synchronization>>, and <<vol1_clause_sdpi_p_aggregators_proxies_sensors>> for additional perspectives and concepts on how SOMDS Connectors may be implemented.
+////
 _<<vol1_spec_sdpi_p_actor_somds_connector>>_ system implementations may support multiple protocols where there is one SOMDS-facing participant model or API but with multiple protocols for non-SOMDS system integration.
 For example, a SOMDS “Alert” Gateway would interact with other _<<vol1_spec_sdpi_p_actor_somds_participant>>s_ in a single consistent way but may support both <<ref_hl7_fhir>> and <<ref_hl7_v2>> protocols for interacting with healthcare enterprise systems.
 
@@ -474,12 +476,13 @@ They shall implement either a <<vol1_spec_sdpi_p_actor_somds_provider>> and / or
 
 The <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> actor identifies and specifies the logic necessary for connecting a SOMDS network environment with Non-SOMDS Systems that utilize <<ref_hl7_fhir>> for their interoperability protocol.  Generally, this logic is defined in the HL7 <<ref_hl7_fhir_pocd_ig>>.
 
-Gateways implementing this actor can support any of the FHIR architectural approaches:  RESTful, messaging, documents, and SOA.
-For example, a <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> can utilize a <<vol1_spec_sdpi_p_actor_somds_consumer>> to retrieve information from other _<<vol1_spec_sdpi_p_actor_somds_participant>>_ systems, map it into FHIR Bundle resources and forward it on to non-SOMDS systems in a FHIR message.
+Gateways implementing this actor can generally support any of the FHIR architectural approaches:  RESTful, messaging, documents, and SOA - although the primary approaches are RESTful and messaging. A specific <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> specification in <<vol2_appendix_b_gateways>> will constrain to (a) specific approach(es). To facilitate interoperability, named options may be added to specialized actors to clearly indicate what a given implementation supports.
+
+For example, a <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> could utilize a <<vol1_spec_sdpi_p_actor_somds_consumer>> to retrieve information from other _<<vol1_spec_sdpi_p_actor_somds_participant>>_ systems, map it into FHIR Bundle resources and forward it on to non-SOMDS systems in a FHIR message.
 
 Alternatively, the <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> could implement a FHIR server and provide support for systems to discover and retrieve information asynchronously, including the use of FHIR publication / subscription (“pub/sub”) services.
 
-The <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> can also support SOMDS services invoked by FHIR-based systems, such as requesting a snapshot of the latest vital signs measurements for a specific patient and triggering a blood-pressure cuff reading.
+The <<vol1_spec_sdpi_p_actor_somds_fhir_gateway>> could also support SOMDS services invoked by FHIR-based systems, such as requesting a snapshot of the latest vital signs measurements for a specific patient and triggering a blood-pressure cuff reading.
 
 [#vol1_clause_sdpi_p_somds_v2_gateway]
 ===== SOMDS V2 Gateway
@@ -541,9 +544,9 @@ For example, an application may only need to identify and consume a few paramete
 Since a single platform actor can support multiple Smart Apps, network traffic may be significantly reduced, as well as processing overhead for <<vol1_spec_sdpi_p_actor_somds_provider>> systems that have multiple <<vol1_spec_sdpi_p_actor_somds_consumer>>s simultaneously invoking their services.
 
 The platform must support both non-smart app critical functions (such as network topology discovery and maintenance) but also aggregate app requirements (e.g., quality of service necessary to support an application’s algorithms).
-
+////
 See <<vol1_clause_smart_app_platforms>> for additional discussion.
-
+////
 ===== BICEPS Content Creator
 [#vol1_spec_sdpi_p_actor_biceps_content_creator, reftext='BICEPS Content Creator']
 Actor Summary Definition:
@@ -821,6 +824,7 @@ To support the <<acronym_soa>>-based connectivity described above, the *_default
 Additional "glue" constraints for this <<acronym_mdpws>> specification are provided in the companion standard: <<ref_ieee_11073_20701_2018>>.
 Specific <<vol1_clause_sdpi_p_profile_reftext>> transaction message bindings and examples are provided in <<vol2_appendix_a_mdpws_messages>>.
 
+////
 ===== General Healthcare vs. Medical Interoperability Purposes
 
 [%noheader]
@@ -829,11 +833,11 @@ Specific <<vol1_clause_sdpi_p_profile_reftext>> transaction message bindings and
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 #TODO: All the transactions here are focused on healthcare information exchange with out any intended medical purpose; relationship to the other SDPi Profiles#
 ////
-
+////
 [#vol1_clause_sdpi_p_ensuring_time_synchronization]
 ===== Ensuring Time Synchronization
 
@@ -843,14 +847,14 @@ a| *{supplement_note}*:  This section intentionally left blank for the current v
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 #TODO: This is a key topic for all health information exchange, and especially that of medical data.  A consuming system has to know, for example, that the time stamps provided in the BICEPS content or in the messages is accurate (and to what degree).  Requirements will be included HERE for SOMDS Participant & all other actors including BICEPS Content <xyz>.  Additional requirements may be added to the TF-3 BICEPS Content Module section as well.
 Integration of CT and ATNA (TBD) below in required groupings is assumed but should be detailed here.#
 
 #TODO: No time sync service identified in 11073 SDC core; include only in the SDPi-P section ... as a requirement to use NTP?; reference resolution of *TS Service*, *MD LAN*, in glossary entries#
 ////
-
+////
 ===== Waveform Communication
 
 [%noheader]
@@ -859,11 +863,11 @@ Integration of CT and ATNA (TBD) below in required groupings is assumed but shou
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 #TODO:  Explain how waveforms are communicated, both snippets and especially "streaming"; include references to appropriate TF-2 & TF-3 Sections; this is part of the "DO WE NEED A WAVEFORM OPTION?" question to help end users? NO!!!  Could drop a note in TF-2 Appendix A for DEV-xyz and how RTSA/Waves would be transmitted / conveyed over the network#
 ////
-
+////
 [#vol1_clause_sdpi_p_aggregators_proxies_sensors]
 ===== Aggregators, Proxies, Sensors
 
@@ -873,7 +877,7 @@ a| *{supplement_note}*:  This section intentionally left blank for the current v
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 ##TODO: :  Include single / multiple patient variations.  See Topic on confluence; ultimately probably in TF-1 & -2 & -3.  NOTE added a section in TF-3 as well.
 Mention SENSORS and WSN referencing SOMDS Sensor Gateways w/ rationale.
@@ -882,7 +886,7 @@ NOTE:  This is not defined in 11073-20701 beyond clause 3. Definitions
 See Gateways in the actors discussion above … and below?
 ##
 ////
-
+////
 ===== Protocol-Specific Gateways
 
 [%noheader]
@@ -891,12 +895,12 @@ See Gateways in the actors discussion above … and below?
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 #TODO: :  External interfaces “gateways” defined in the abstract and in the protocol-specific.  These actors are leveraged in other profiles such as SDPi-Reporting for a DEC Gateway or in SDPi-Alerting for an ACM gateway.  Include proprietary protocols as well.
 Given the discussion in Actors above, is this necessary here?  Or should some of that content be moved here?  YES … show examples for how the Actors might be grouped into a real-world gateway to … for example … an EHR etc.]#
 ////
-
+////
 [#vol1_clause_smart_app_platforms]
 ===== Smart App Platforms
 
@@ -906,11 +910,11 @@ Given the discussion in Actors above, is this necessary here?  Or should some of
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 #TODO: 1.	This section enhances the short actor description above to describe in more detail the various aspects of an application “platform”; see Word draft Section 10.4.1.5 for additional content#
 ////
-
+////
 ===== Workflow vs. Transport Actors and Interactions
 
 [%noheader]
@@ -919,7 +923,7 @@ a| *{supplement_note}*:  This section intentionally left blank for the current v
 |===
 a| *{supplement_note}*:  This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
 |===
-
+////
 ////
 #TODO: discuss the challenges of drawing a line between transport profile actors in SDPi and applications of those actors in more care context / workflow applications, such as Smart Alarming or MDIRA/ICE or ICU Integration etc.  Reference General Introduction profile "types" - workflow vs. transport vs. content (???) ]#
 ////
@@ -952,7 +956,11 @@ This use case fully addresses the requirements from  <<vol1_clause_appendix_c_us
 Specific capabilities supporting the <<acronym_stad>> use case include:
 
 * *System Type*:  <<acronym_md_lan>> supported by SDPi-P <<acronym_pnt>> capabilities (see <<vol1_figure_sdpi_p_example_sequence_diagram>>)
-* *Service Type*:  <<acronym_ts_service>> supported by *Consistent Time* Profile binding (see <<vol1_clause_sdpi_p_ensuring_time_synchronization>>)
+* *Service Type*:  <<acronym_ts_service>> supported by *Consistent Time* Profile binding
+
+////
+(see <<vol1_clause_sdpi_p_ensuring_time_synchronization>>)
+////
 * *Technical Pre-Conditions*:  <<acronym_stad>> <<vol1_clause_appendix_c_use_case_stad_technical_precondition>> are fully supported by SDPi-P
 * *Scenarios*:  <<acronym_stad>> <<vol1_clause_appendix_c_use_case_stad_scenarios>> are fully supported by SDPi-P
 

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

@@ -8,8 +8,8 @@
 [cols="1"]
 |===
 a| *{supplement_note}*:  This version of the <<acronym_sdpi_r>> Profile is built upon the foundational <<acronym_sdpi_p>> Profile but does not provide substantially more capabilities.
-This is due to the fact that the primary purpose of this <<acronym_sdpi_r>> Profile, namely communication of medical data to accomplish intended medical purposes, requires the completion and integration of two emerging ISO/IEEE standards:  <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>.
-When these are published *_in 2023 / 2024_*, their requirements will be integrated into this supplement, with their <<term_implementation_conformance_statement>> added to <<vol1_appendix_b_referenced_standards_conformance>> below.
+This is due to the fact that the primary purpose of this <<acronym_sdpi_r>> Profile, namely communication of medical data to accomplish intended medical purposes, requires the full integration of two emerging ISO/IEEE standards:  <<ref_ieee_11073_10700_2022>> and <<ref_ieee_11073_10701_2022>>.
+Their requirements will be integrated into this supplement, with their <<term_implementation_conformance_statement>> added to <<vol1_appendix_b_referenced_standards_conformance>> below.
 Many of those requirements will be mapped to the actors and transactions and other elements in this supplement, including this <<acronym_sdpi_r>> Profile.
 
 Additionally, though the <<actor_somds_dec_gateway>> is defined below and fully specified in <<vol2_clause_appendix_sdpi_dec_gateway>>, the implementation guide for mapping from <<acronym_biceps>> to <<acronym_hl7>> <<acronym_fhir>> remains in development, pushing the specification of the <<vol1_spec_sdpi_r_actor_somds_fhir_medical_data_gateway>> to a later version of this supplement.

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

@@ -9,7 +9,7 @@
 |===
 a| *{supplement_note}*:  This initial version of the <<acronym_sdpi_a>> Profile is built upon the foundational <<acronym_sdpi_p>> Profile but adds services specialized for the communication and management of medical device alerting.
 Additionally, since the primary purpose of this specification is the communication of medical alert information to accomplish intended medical purposes, it will require the completion and integration of the emerging ISO/IEEE 11073 Alert <<acronym_pkp>> standard  <<ref_ieee_11073_10702_202x>>.
-When this new standard is published *_in 2024_*, its requirements will be integrated into this supplement, with its <<term_implementation_conformance_statement>> added to <<vol1_appendix_b_referenced_standards_conformance>>.
+When this new standard is published, its requirements will be integrated into this supplement, with its <<term_implementation_conformance_statement>> added to <<vol1_appendix_b_referenced_standards_conformance>>.
 Many of those requirements will be mapped to the actors, transactions and other specifications in this specification.
 
 Two of the transactions identified below, [DEV-41] and [DEV-42] are related to Medical Alert Delegation; however, at this stage there is considerable standards development activity to update the current <<acronym_sdc>> standards, particularly in association with completing the Alert <<acronym_pkp>> standard  <<ref_ieee_11073_10702_202x>>.
@@ -18,7 +18,7 @@ As a result, the completion of these two transactions has been deferred to a sub
 Similarly, a related transaction, [DEV-43], namely providing clinician alert acknowledgement status information back to the alerting device, is also being discussed further and will be deferred to a subsequent version of the supplement.
 
 Finally, it should be noted that  <<actor_somds_acm_gateway>> is defined below and fully specified in <<vol2_clause_appendix_sdpi_acm_gateway>>.
-Also in development is <<acronym_hl7>> <<acronym_fhir>> support for medical alerting (e.g., definition of a <<acronym_fhir>> DeviceAlert resource); however, that will not be completed until 2024 or beyond.
+Also in development is <<acronym_hl7>> <<acronym_fhir>> support for medical alerting (e.g., refinement of the <<acronym_fhir>> DeviceAlert resource).
 As a result, a "SOMDS Medical Alert FHIR Gateway" is not included as an actor at this stage; however, it is expected to be added in the coming year or two.
 
 |===

asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc

@@ -7,7 +7,7 @@
 [%autowidth]
 [cols="1"]
 |===
-a| *{supplement_note}*: This SDPi-xC (External Control) Profile Section is generally out-of-scope for this version of the profile (see https://github.com/orgs/IHE/projects/6/views/1["Gemini SDPi Releases" Github project]); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions.  Depending on capabilities, some very basic controls may need to be provided in 2024 as part of the 1.x or 2.0 versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading).
+a| *{supplement_note}*: This SDPi-xC (External Control) Profile Section is generally out-of-scope for this version of the profile (see https://github.com/orgs/IHE/projects/6/views/1["Gemini SDPi Releases" Github project]); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided as part of the 2.X or 3.X versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading).
 
 |===
 

asciidoc/volume1/tf1-ch-2-overview.adoc

@@ -145,7 +145,7 @@ Profile options are provided for additional capabilities that may be required to
 [sdpi_offset=12]
 ==== Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile
 The SDPi Alerting Profile builds on the basic <<acronym_pnt>> capabilities of the <<acronym_sdpi_p>> profile, but adds the requirements to fully support *_medical alerting_*.
-To that end, this specification implements the safety and security requirements of the <<ref_ieee_11073_10702_202x>> alert <<acronym_pkp>> standard (expected to be completed in 2024).
+To that end, this specification implements the safety and security requirements of the <<ref_ieee_11073_10702_202x>> alert <<acronym_pkp>> standard (expected to be completed in 2025).
 
 The profile supports core medical alerting functionality needed by all participating systems.
 Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., alert delegation).