528 standalone sdpi editorial content update

.ci/asciidoc-converter/build_standard.bat

@@ -0,0 +1,3 @@
+mkdir ..\..\sdpi-documents
+mkdir ..\..\sdpi-documents\sdpi-standard
+gradlew.bat run --args="--input-file ../../asciidoc/sdpi-standard.adoc --output-folder ../../sdpi-documents/sdpi-standard --backend html"

.ci/asciidoc-converter/build_standard_debug.bat

@@ -0,0 +1,3 @@
+mkdir ..\..\sdpi-documents
+mkdir ..\..\sdpi-documents\sdpi-standard
+gradlew.bat run --args="--input-file ../../asciidoc/sdpi-standard.adoc --output-folder ../../sdpi-documents/sdpi-standard --backend html"  --debug

.ci/asciidoc-converter/build_supplement.bat

@@ -0,0 +1,3 @@
+mkdir ..\..\sdpi-documents
+mkdir ..\..\sdpi-documents\sdpi-supplement
+gradlew.bat run --args="--input-file ../../asciidoc/sdpi-supplement.adoc --output-folder ../../sdpi-documents/sdpi-supplement --backend html"

CHANGELOG.md

@@ -20,6 +20,8 @@ Each section shall contain a list of action items of the following format: `<bri
 
 - History Service design, MDPWS requirements and transactions ([#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)).
+- Standalone SDPi - Editorial Content Update to the Standard and Supplement documents ([#528](https://github.com/IHE/DEV.SDPi/issues/528)).
 - 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)).

asciidoc/conformance/conformance.adoc

@@ -0,0 +1,8 @@
+
+[#clause_conformance,sdpi_offset=clear]
+= Conformance
+
+NOTE: #This new clause will include all referenced standards conformance information as well as other SDPi conformance info.#
+
+
+

asciidoc/front-matter/copyrights.adoc

@@ -0,0 +1,45 @@
+
+-== Copyright Licenses
+IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-9.html[Section 9 - Copyright Licenses] for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there.
+
+==== Copyright of Base Standards
+
+===== IEEE 11073 (Health Device Interoperability)
+
+[%noheader]
+[%autowidth]
+[cols="1"]
+|===
+a| *{standard_note}*:  The content below is verbatim from the IEEE permission letter.
+An abbreviated version may be provided in subsequent standard versions with a reference to the complete letter.
+
+The copyright language will need to be updated to support future PKP standards <<ref_ieee_11073_10702_202x>> and <<ref_ieee_11073_10703_202x>>.
+
+Note that NIST and the RTTMS tools are a key factor in the nomenclature aspect of the licensing discussion.
+
+|===
+
+IEEE^®^ and IEEE 11073^®^ are registered trademarks of the The Institute of Electrical and Electronics Engineers, Inc.  IEEE has granted permission to IHE and HL7 to use portions of 11073-10207, 11073-20701, 11073-20702, 11073-10700, 11073-10701 (the “Material”), subject to the following conditions:
+
+. IHE’s use of the Material shall be for the following purpose: (the “Purpose”):
+
+* IHE specification developers want to include the Implementation Conformance Specification (ICS) tables from each of these standards and add to the "Support" column the specifics of how and where the IHE specifications address the SDC capability.
+
+* Additionally, the IHE profile specifications may include summarization and references to specific content and in a few cases, inclusion of a graphic that would then point the reader back to standard for detailed review. For example, 11073-10207, Figure 2 "BICEPS component decomposition".
+
+* Finally, all three of these standards have integrated requirement designations. For example, 11073-20701, Section (10.1) "R0064: An SDC PARTICIPANT SHOULD utilize the highest TLS version." These requirements may also be referenced (at least by Rxxxx designator) to indicate when and how they are addressed in the IHE specification(s). IHE agrees to share with the 11073 working groups any iteration of its derivative work for the benefits of the 11073 community of users.
+
+. IHE understands and agrees that the following shall appear in each section where the material is used:
+
+* _Adapted and reprinted with permission from IEEE. Copyright IEEE Year.  All rights reserved._*  footnote:ieee_permission[Adapted and reprinted with permission from IEEE. Copyright IEEE Year.  All rights reserved.]
+
+. IHE understands and agrees that the Material is the intellectual property of IEEE. Except as provided in this agreement no ownership rights to the Material shall be transferred to IHE.
+
+. Except as necessary to give effect to the Purpose, no other use of the Material including, but not limited to, reproduction or distribution of the IEEE Standards in any format is prohibited without prior written consent of IEEE.
+
+. The Material is provided “as is,” To the extent permitted by law, IEEE disclaims all representations and warranties to the Material.
+
+. IHE shall note that any comments or interpretations of the Material are its own and do not represent the views of IEEE, its members or affiliates.
+
+. IHE understands and agrees that this grant permission may not be transferred or assigned without the express written permission of IEEE.
+

asciidoc/document-declarations.adoc → asciidoc/front-matter/document-declarations.adoc

@@ -9,23 +9,21 @@ NOTES:
 
 ////
 
-[#supplement_clause_forward_declarations,sdpi_offset=clear]
+[#standard_clause_forward_declarations,sdpi_offset=clear]
 == Standard Forward Declarations
 
 [%noheader]
 [%autowidth]
 [cols="1"]
 |===
-a| *{supplement_note}*:
-
-*Standalone SDPi:*  _REWORK this section to make it a permanent Forward Declarations, perhaps refactoring it into something that is not labeled "Forward Declarations"!_
+a| *{standard_note}*:
 
 The following table is included in this version of the standard to capture *_"forward" declarations of acronyms and labels_* that are used in the text but are not intended to be part of the General Introduction Appendix D Glossary.
 "Forward" means that they are used BEFORE the document section in which they are formally defined.
 Since AsciiDoc is a one-pass processor, forward declarations are required.
 
 There was no clear way of defining these replacement definitions in a way that is "under the hood" and not visible to the reader.
-The following table was thus created but may be moved or otherwise implemented in subsequent supplement versions.
+The following table was thus created but may be moved or otherwise implemented in subsequent standard versions.
 
 Suggestions appreciated!
 

asciidoc/front-matter/forward.adoc

@@ -0,0 +1,36 @@
+
+[#standard_clause_foreword,sdpi_offset=clear]
+= Foreword
+
+== HL7-IHE Gemini Device Interoperability Program
+
+Recognizing the decades-long close collaboration between between Health Level Seven International (HL7) and Integrating the Healthcare Enterprise (IHE), and in order to better facilitate coordinated development, the Gemini Program was created as a home for joint projects.
+This Gemini standard is one such joint development project between the HL7 and IHE Devices working groups focused on acute care, plug-and-trust medical device interoperability.
+Its development and publication adheres to the consensus standards processes of both HL7, an ANSI accredited standards development organization, and IHE.
+The title of this document, *_Technical Framework Profile Standard_*, reflects its unique status as a Gemini specification, utilizing the IHE Technical Framework organization and elements (e.g., integration profiles, actors, transactions, content modules), but processed as an HL7 specification that will be published as a "standalone" standard and will persist even when its status transitions to normative standard (HL7) or Final Text (IHE).
+
+To facilitate integration with the companion IHE Devices Technical Framework (final text) specification, a companion to this standard is created for each edition:  "IHE Devices Technical Framework _Supplement_ -- Service-oriented Device Point-of-care Interoperability (SDPi)", which will be organized and adhere to IHE style guidelines for supplement documents, but it will be in major section outline only, with each section including a note indicating where the content is located in the published *Gemini Technical Framework Profile _Standard_* (this document).
+Given its alignment with the companion IHE specification, some section numbers are skipped in this document to facilitate its intended integration into the above-mentioned "standard".
+Skipped section numbers are already present in the Devices Technical Framework and will not require changes due to the incorporation of the supplement once it transitions to normative standard / final text status.
+
+Additionally, some content that may otherwise be only referenced by a "supplement" document and defined elsewhere in the existing technical framework, will be incorporated in this specification to ensure that it is internally cohesive and does not force the reader to unnecessarily consult other documents.
+
+Publication as a *Standard for Trial Use* (HL7 STU) or *Trial Implementation* (IHE TI) reflects the continuous cycle of development, balloting and publication of the specification, to address addition of new capabilities as well as identified safety, effectiveness and security issues and enhancements.
+Product developers are encouraged to use the standard, recognizing the potential impact of this continuous development cycle and its status as a _"trial use"_ standard.
+
+
+This supplement is published on {ihe_standard_sdpi_publication_month} for Trial Implementation and may be available for testing at subsequent IHE or HL7 testing events, such as an IHE Connectathon.
+The standard may be amended based on the results of testing.
+Following successful testing and implementation maturity, it will transition to a normative standard, and the companion IHE supplement will be incorporated into the Devices Technical Framework.
+Comments are invited and can be submitted at https://www.ihe.net/DEV_Public_Comments/[Devices Public Comments] or by submitting a https://github.com/IHE/DEV.SDPi/issues/new/choose[GitHub Issue].
+
+General information about IHE can be found at http://www.ihe.net/[IHE.net], and about HL7 can be found at https://www.hl7.org/index.cfm[HL7.org].
+
+General information about the HL7 Devices Working Group can be found at https://www.hl7.org/Special/committees/healthcaredevices/index.cfm[HL7.org/healthcaredevices], and the IHE Devices domain can be found at https://www.ihe.net/ihe_domains/[IHE Domains].
+
+Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at https://www.ihe.net/resources/profiles/[Profiles] and https://www.ihe.net/about_ihe/ihe_process/[IHE Processes].
+
+The current version of the IHE Devices Technical Framework can be found at https://profiles.ihe.net/DEV/[DEV Technical Framework].
+
+include::standard-issues.adoc[]
+