Merge branch 'master' into 252-add-support-for-fhir-based-gateways-to…

…-sdpi-p-r-a

CHANGELOG.md

@@ -18,12 +18,16 @@ 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))
+- Clarified that the SES sections are not comprehensive for risk management ([#271](https://github.com/IHE/DEV.SDPi/issues/271))
 
 ### 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))
 
 
 ## [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/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/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.