Merge branch 'master' into 202-time-synchronization-requirements

.github/ISSUE_TEMPLATE/general.md

@@ -4,4 +4,5 @@ about: Files a task
 title: ""
 assignees: ''
 labels: "Comment NEW"
+projects: ["IHE/Projects/Gemini SDPi Releases", "IHE/6"]
 ---

CHANGELOG.md

@@ -17,10 +17,17 @@ Each section shall contain a list of action items of the following format: `<bri
 
 ### Added
 
+- Requirements R0019 and R0020 to prohibit the use of QNames and XML mixed content ([#210](https://github.com/IHE/DEV.SDPi/issues/210).
+- Requirements R1012 and R1013 to process QNames in BICEPS and DPWS ([#210](https://github.com/IHE/DEV.SDPi/issues/210).
+- Scope of Application section added to TF-1 SDPi Overview ([#235](https://github.com/IHE/DEV.SDPi/issues/235))
+- Update Title Page to Better Reflect HL7 Aspects of the SDPi Standard ([#240](https://github.com/IHE/DEV.SDPi/issues/240))
+
 ### Changed
 
 ### Removed
 
+- _OBX-17 field is not left empty_ as this would be interpreted as derivation method _auto_ ([#233](https://github.com/IHE/DEV.SDPi/issues/233).
+
 ### Editorial Fixes
 
 ## [1.1.0] - 2023-07-21
@@ -68,3 +75,4 @@ Each section shall contain a list of action items of the following format: `<bri
 - Replaced high-lighting from "Closed Issues" section with correct list ([#139](https://github.com/IHE/DEV.SDPi/issues/139)).
 - Remove leading dashes from table and figure captions if the section number is empty ([#144](https://github.com/IHE/DEV.SDPi/issues/144)).
 - Reviewed all "Verson Note" and version-specific (i.e, 1.0) content and either reworded or removed ([#148](https://github.com/IHE/DEV.SDPi/issues/148))
+

asciidoc/sdpi-supplement.adoc

@@ -22,7 +22,7 @@
 
 :ihe_supplement_sdpi_revision: 1.1.0
 :ihe_supplement_sdpi_revision_date: {localdatetime}
-:ihe_supplement_sdpi_revision_label: Trial Implementation
+:ihe_supplement_sdpi_revision_label: Standard for Trial Use / Implementation
 :ihe_supplement_sdpi_publication_month: July 21, 2023
 :ihe_supplement_sdpi_public_comment_submission_deadline: N/A
 
@@ -38,8 +38,8 @@
 ++++
 <div class="logos">
     <div>
-        <img src="{imagesdir}ihe-logo.svg"/>
         <img src="{imagesdir}hl7-intl-logo.svg"/>
+        <img src="{imagesdir}ihe-logo.svg"/>
     </div>
     <div><strong>A Joint HL7-IHE Gemini Device Interoperability Project</strong></div>
 </div>
@@ -67,7 +67,7 @@
 | {ihe_supplement_sdpi_revision_date}
 
 | *Author:*
-| Devices Technical Committee / DPI Program
+| HL7 Devices Working Group & IHE Devices Technical Committee
 
 | *Email:*
 | [email protected]
@@ -76,14 +76,21 @@
 {empty} +
 
 *Please verify you have the most recent version of this document.*
-See https://profiles.ihe.net/DEV/[*HERE*] for Trial Implementation and Final Text versions and https://profiles.ihe.net/DEV/#1.2[*HERE*] for Public Comment versions.
+See https://profiles.ihe.net/DEV/[*HERE*] for STU/Trial Implementation and Final Text versions and https://profiles.ihe.net/DEV/#1.2[*HERE*] for Public Comment versions.
+
+A PDF version of the specification is available upon request.
 
 {empty} +
 
 
 [#supplement_clause_foreword,sdpi_offset=clear]
 = Foreword
 
+This Gemini standard is a joint development effort between Health Level Seven International (HL7) and Integrating the Healthcare Enterprise (IHE) devices working groups.
+Its development and publication adheres to the consensus standards processes of both HL7, an ANSI accredited standards development organization, and IHE.
+Publication as a Standard for Trial Use (HL7) or Trial Implementation (IHE) 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.
+
 This is a supplement to the IHE Devices Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.
 
 This supplement is published on {ihe_supplement_sdpi_publication_month} for Trial Implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it 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].

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

@@ -21,17 +21,17 @@
 |New Glossary Term |Definition |Synonyms |Acronyms / Abbreviation |References |Type
 
 | [[term_american_national_standards_institute,American National Standards Institute (ANSI)]] American National Standards Institute
-| The primary United States <<acronym_sdo>> recognition and facilitation organization.  See https://ansi.org/[ANSI.org] for more information.
+| The primary United States <<acronym_sdo>> recognition and facilitation organization.
 |
 | [[acronym_ansi,ANSI]] ANSI
-|
+| https://ansi.org/[ANSI.org]
 | Organization
 
 |[[term_basic_ice_protocol_specification,Basic ICE Protocol Specification (BICEPS)]] Basic ICE Protocol Specification
-| General reference to the abstract, implementation technology independent SDC components defined in the ISO/IEEE 11073-10207 standard.  (See <<ref_ieee_11073_10207_2017>>)
+| General reference to the abstract, implementation technology independent SDC components defined in the ISO/IEEE 11073-10207 standard.
 |
 | [[acronym_biceps,BICEPS]] BICEPS
-|
+| <<ref_ieee_11073_10207_2017>>
 | SDC
 
 | [[term_central_station,Central Station]] Central Station
@@ -148,10 +148,10 @@
 | Organization
 
 | Local Area Network
-| A computer network that interconnects computers within a limited area such as a hospital, ICU bed, laboratory, or office building. By contrast, a wide area network (WAN) not only covers a larger geographic distance, but also generally involves leased telecommunication circuits. See https://en.wikipedia.org/wiki/Local_area_network["Local area network" article] for more information and references.
+| A computer network that interconnects computers within a limited area such as a hospital, ICU bed, laboratory, or office building. By contrast, a wide area network (WAN) not only covers a larger geographic distance, but also generally involves leased telecommunication circuits.
 |
 | [[acronym_lan,LAN]] LAN
-|
+| See https://en.wikipedia.org/wiki/Local_area_network["Local area network" article] for more information and references.
 |
 
 | [[term_manufacturer, Manufacturer]] Manufacturer

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

@@ -51,10 +51,33 @@ In this version, the content is added as 2.3.1, and then the profiles as 2.3.10
 
 |===
 
+[#vol1_clause_sdpi_integration_profiles_overview]
+==== Service-oriented Device Point-of-care Interoperability (SDPi)
+
+
+[#vol1_clause_sdpi_scope]
+===== SDPi Profiles – Scope of Application
+
+The Service-oriented Device Point-of-care Interoperability (SDPi) Profile specifications encompass the following application scope:
+
+[none]
+. The SDPi specifications provide detailed instructions for seamless plug-and-play interoperability between ISO/IEEE 11073 SDC-based medical devices (including SaMD), as well as between medical devices and health IT systems based on HL7 FHIR and HL7 Version 2.
+Key considerations include enabling safe, secure and effective interoperability for data reporting, alert notification, device-external control and other high-acuity point-of-care  use cases.
+Provision is made for coordination of individual device functional contributions to support clinical system functions that are provided by two or more participants.
+
+
+Notes:
+
+1. High-acuity points of care include operating rooms (OR), intensive care units (ICU), step-down units, and emergency care.
+2. Clinical system function example:  Physiological monitoring of a patient's condition as they are being weaned off of a ventilator.
+3. "SaMD" is Software as a Medical Device, including "clinical apps"; they are a class of Health Software.
+4. ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards provide a Services Oriented Architecture (SOA) specification for safe, effective and secure medical device interoperability (SES MDI).
+
+
 [#vol1_clause_sdpi_overview_framework]
-==== Service-oriented Device Point-of-care Interoperability (SDPi) – Overview & Framework
+===== SDPi Profiles – Overview & Framework
 
-The Service-oriented Device Point-of-care Interoperability (SDPi) Profiles are built upon a foundation of standards and profiles from <<acronym_hl7>>, <<acronym_ieee>>, IHE and other organizations.  An overview of the profiles and their relationships is provided in <<figure_sdpi_profiles_foundational_standards>>.
+The SDPi Profiles are built upon a foundation of standards and profiles from <<acronym_hl7>>, <<acronym_ieee>>, IHE and other organizations.  An overview of the profiles and their relationships is provided in <<figure_sdpi_profiles_foundational_standards>>.
 
 .IHE SDPi Profiles & Foundational Standards
 [#figure_sdpi_profiles_foundational_standards]

asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc

@@ -402,7 +402,7 @@ Note that the *pm:AlertConditionState+++<wbr/>+++/pm:DeterminationTime* changes
 
 [sdpi_level=+1]
 ====== Physiological Alerts
-The event identification mapping for a physiological alert is defined in table <<ref_tbl_acm_obx_event_phy_mapping>>.
+The event identification mapping for a physiological alert (alarm or advisory) is defined in table <<ref_tbl_acm_obx_event_phy_mapping>>.
 
 .R8063
 [sdpi_requirement#r8063,sdpi_req_level=shall]
@@ -481,13 +481,13 @@ Please refer to <<ref_acm_containment_tree_mapping>> for further information.
 
 .OBX Event Identification Mapping - Physiological Alert Event
 ====
-OBX|4|ST|196648\^MDC_EVT_HI^MDC|1.1.1.1.1|**ABPs 119>110||||||R|||20191121102600||||XY150Z0409\^^0009FBFFFF059322^EUI-64
+OBX|4|ST|196648\^MDC_EVT_HI^MDC|1.1.1.1.1|**ABPs 119>110||||||R|||20191121102600||||2A144AFE-7AD5-4549-95F9-BD805319CB47\^^2A144AFE-7AD5-4549-95F9-BD805319CB47^UUID
 ====
 
 
 [sdpi_level=+1]
 ====== Technical Alerts
-The event identification mapping for a technical alert is defined in table <<ref_tbl_acm_obx_event_tec_mapping>>.
+The event identification mapping for a technical alert (alarm or advisory) is defined in table <<ref_tbl_acm_obx_event_tec_mapping>>.
 
 .R8064
 [sdpi_requirement#r8064,sdpi_req_level=shall]
@@ -588,7 +588,7 @@ In all other cases, the field is required to be set to pm:AlertConditionDescript
 
 .OBX Event Identification Mapping - Technical Alert Event
 ====
-OBX|4|CWE|196616\^MDC_EVT_ALARM^MDC|1.1.1.1.1|196882\^MDC_EVT_LEADS_OFF^MDC^^^^^^!! ECG Leads Off||||||R|||||||XY150Z0409\^^0009FBFFFF059322^EUI-64
+OBX|4|CWE|196616\^MDC_EVT_ALARM^MDC|1.1.1.1.1|196882\^MDC_EVT_LEADS_OFF^MDC^^^^^^!! ECG Leads Off||||||R|||||||2A144AFE-7AD5-4549-95F9-BD805319CB47\^^2A144AFE-7AD5-4549-95F9-BD805319CB47^UUID
 ====
 
 [#ref_acm_obx_source_id_mapping]
@@ -626,7 +626,7 @@ For a technical or advisory alert event, a <<actor_somds_acm_gateway>> shall set
 .R8066
 [sdpi_requirement#r8066,sdpi_req_level=shall]
 ****
-A <<actor_somds_acm_gateway>> shall map the source identification for physiological alerts to an OBX segment as defined in <<ref_dec_obx_mapping>>. The gateway captures the state of the related metric at the time the alert event occurred.
+A <<actor_somds_acm_gateway>> shall map the source identification for physiological alerts (alarms or advisories) to an OBX segment as defined in <<ref_dec_obx_mapping>>. The gateway captures the state of the related metric at the time the alert event occurred.
 
 .Notes
 [%collapsible]
@@ -654,7 +654,7 @@ OBX|5|NM|150037\^MDC_PRESS_BLD_ART_ABP_SYS^MDC|1.1.1.1.2|119|266016\^MDC_DIM_MMH
 
 [sdpi_level=+1]
 ====== Technical Alerts
-The source identification mapping for a technical alert is defined in table <<ref_tbl_acm_obx_source_tec_mapping>>.
+The source identification mapping for a technical alert (alarm or advisory) is defined in table <<ref_tbl_acm_obx_source_tec_mapping>>.
 
 .R8069
 [sdpi_requirement#r8069,sdpi_req_level=shall]
@@ -1024,7 +1024,6 @@ Please refer to <<ref_acm_containment_tree_mapping>> for further information.
 |Observation Result Status
 |
 |Set to *"R"*.
-
 |===
 
 [#ref_tbl_alert_inactivation_state_mapping]
@@ -1166,6 +1165,11 @@ pm:AlertConditionDescriptor
 
 |===
 
+[NOTE]
+====
+If a <<acronym_sdc>> ALERT CONDITION represents an avisory signal, the alert priority is set to *"None"* for this <<acronym_sdc>> ALERT CONDITION, and therefore, mapped to *"PN"* in the IHE ACM Alert Priority OBX segment.
+====
+
 ====== Alert Type OBX Segment
 .R8076
 [sdpi_requirement#r8076,sdpi_req_level=shall]
@@ -1185,6 +1189,19 @@ OBX|10|ST|68485\^MDC_ATTR_ALERT_TYPE^MDC|1.1.1.1.7|ST||||||R
 ====
 ****
 
+.R8079
+[sdpi_requirement#r8079,sdpi_req_level=shall]
+****
+If *pm:AlertConditionState+++<wbr/>+++/@ActualPriority* is available and set to *"None"*, or if *pm:AlertConditionState+++<wbr/>+++/@ActualPriority* is NOT available and *pm:AlertConditionDescriptor+++<wbr/>+++/@Priority* set to *"None"*, then the <<acronym_sdc>> ALERT CONDITION is an advisory, and the alert type shall be set to *"SA"* in the IHE ACM Alert Type OBX segment.
+
+.Examples
+[%collapsible]
+====
+OBX|10|ST|68485\^MDC_ATTR_ALERT_TYPE^MDC|1.1.1.1.7|SA||||||R
+====
+****
+
+
 [#ref_tbl_acm_obx_alert_type_mapping]
 .OBX Alert Type Mapping
 |===
@@ -1244,11 +1261,15 @@ Please refer to <<ref_acm_containment_tree_mapping>> for further information.
 |SP
 |Alert is Alarm – Physiological
 
+See exception when <<r8079>> is met.
+
 |Tec
 |Tec = Technical. The condition arises from a monitored equipment-related or ALERT SYSTEM-related variable.
 |ST
 |Alert is Alarm – Technical
 
+See exception when <<r8079>> is met.
+
 |Oth
 |Oth = Other. The condition arises from another origin, e.g., equipment-user
 advisory condition.

asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc

@@ -825,9 +825,7 @@ A <<actor_somds_dec_gateway>> should repeat the OBX-17 field to express the *pm:
 
 |Msmt
 |Auto
-|OBX-17 field is left empty (recommended).
-
-Or set to "AMEAS\^auto-measurement^MDC" if required.
+|AMEAS\^auto-measurement^MDC
 
 |Msmt
 |Man
@@ -854,12 +852,13 @@ Or set to "AMEAS\^auto-measurement^MDC" if required.
 [#ref_tbl_dec_obx17_mapping2]
 .OBX-17 Observation Method Mapping
 |===
-|HL7 Field |HL7 Component Name |SDC Attribute/Element |Comments
+|SDC MetricAvailability |HL7 OBX-17 Field Value
 
-|OBR-17/CWE-1
-|Identifier
-|pm:AbstractMetricDescriptor+++<wbr/>+++/@MetricAvailability
-|
+|Cont
+|69123\^MDC_OBS_CTS^MDC
+
+|Int
+|69124\^MDC_OBS_NONCTS^MDC
 
 |===
 

asciidoc/volume2/gateways/tf2-ch-b-gateway-msh-mapping.adoc

@@ -11,7 +11,13 @@ If not differently specified in this section, the MSH segment fields shall be in
 .R8101
 [sdpi_requirement#r8101,sdpi_req_level=shall,sdpi_max_occurrence=1]
 ****
-If the <<acronym_mdib>> contains several MDS elements that could operate in different *pm:MdsState/@OperatingMode* states, there shall be a separate [PCD-01] message per MDS.
+For each <<acronym_mds>> element in the <<acronym_mdib>>, a separate [PCD-01] message shall be exported.
+
+.Notes
+[%collapsible]
+====
+NOTE: The HL7 segments *MSH*, *PID*, and *PV1* contain information which can differ between multiple <<acronym_poc>> devices represented as <<acronym_mds>> elements in the <<acronym_mdib>> (e. g. operating mode, patient demographics, patient location, etc.). Since these segments are commonly defined for all <<acronym_mds>> elements in the HL7 [PCD-01] message, separate HL7 [PCD-01] messages per <<acronym_pocd>> are required to be exported.
+====
 ****
 
 ====== MSH-11 Processing ID