diff --git a/.ci/asciidoc-converter/src/main/kotlin/org/sdpi/asciidoc/extension/ReferenceSanitizerPostprocessor.kt b/.ci/asciidoc-converter/src/main/kotlin/org/sdpi/asciidoc/extension/ReferenceSanitizerPostprocessor.kt index f05f74e..d9b5be5 100644 --- a/.ci/asciidoc-converter/src/main/kotlin/org/sdpi/asciidoc/extension/ReferenceSanitizerPostprocessor.kt +++ b/.ci/asciidoc-converter/src/main/kotlin/org/sdpi/asciidoc/extension/ReferenceSanitizerPostprocessor.kt @@ -82,7 +82,7 @@ class ReferenceSanitizerPostprocessor( val anchorText = (encodedLabel?.let { decodeLabel(it) }) ?: item.refText when (item.source) { - LabelSource.SECTION -> anchor.text(anchorText ?: "$sectionSig${item.label}") + LabelSource.SECTION -> anchor.text(anchorText ?: "$sectionSig${item.prefix}:${item.label}") LabelSource.TABLE_OR_FIGURE -> anchor.text(anchorText ?: item.label) LabelSource.APPENDIX -> anchor.text(anchorText ?: "$appendixSig${item.prefix}:${item.label}") LabelSource.VOLUME -> anchor.text(anchorText ?: "$chapterSig${item.prefix}") diff --git a/CHANGELOG.md b/CHANGELOG.md index b71088a..9d6f43a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -33,14 +33,20 @@ Each section shall contain a list of action items of the following format: `> consumer: Hello(Provider UID, Discovery Scope) diff --git a/asciidoc/plantuml/vol2-figure-dev-24-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-24-sequence.puml index 38e0f44..17d8219 100644 --- a/asciidoc/plantuml/vol2-figure-dev-24-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-24-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -==SDPi [DEV-24] Discover Network Topology== +==SDPi Discover Network Topology [DEV-24]== alt consumer ->> provider: Probe(Discovery Scope) diff --git a/asciidoc/plantuml/vol2-figure-dev-25-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-25-sequence.puml index 5139eeb..a550b8d 100644 --- a/asciidoc/plantuml/vol2-figure-dev-25-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-25-sequence.puml @@ -8,7 +8,7 @@ autonumber participant "$str_sdpi_p_somds_cons" as sdpi_somds_consumer participant "$str_sdpi_p_somds_prov" as sdpi_somds_provider -==SDPi [DEV-25] Discover BICEPS Services== +==SDPi Discover BICEPS Services [DEV-25]== sdpi_somds_consumer -> sdpi_somds_provider: GetMetadata() sdpi_somds_consumer <<-- sdpi_somds_provider: GetMetadataResponse(BICEPS Services, Device Metadata, Model Metadata) diff --git a/asciidoc/plantuml/vol2-figure-dev-27-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-27-sequence.puml index 11b4a8a..9280669 100644 --- a/asciidoc/plantuml/vol2-figure-dev-27-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-27-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -==SDPi [DEV-27] Manage BICEPS Subscription== +==SDPi Manage BICEPS Subscription [DEV-27]== consumer -> provider: Subscribe(Filter, Expiration Time) consumer <<-- provider: SubscribeResponse(Subscription Manager, Expiration Time) diff --git a/asciidoc/plantuml/vol2-figure-dev-28-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-28-sequence.puml index 52ed618..e22048d 100644 --- a/asciidoc/plantuml/vol2-figure-dev-28-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-28-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-28] Notify Change in System Context and Capabilities == +==SDPi Notify Change in System Context and Capabilities [DEV-28]== consumer <<- provider: Notification(EpisodicContextReport) diff --git a/asciidoc/plantuml/vol2-figure-dev-29-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-29-sequence.puml index 3fc0b19..55b17bf 100644 --- a/asciidoc/plantuml/vol2-figure-dev-29-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-29-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-29] Publish BICEPS Update Reports == +==SDPi Publish BICEPS Update Reports [DEV-29]== opt consumer <<- provider: Notification(EpisodicAlertReport) end diff --git a/asciidoc/plantuml/vol2-figure-dev-30-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-30-sequence.puml index 87ef92c..a0a81e0 100644 --- a/asciidoc/plantuml/vol2-figure-dev-30-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-30-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-30] Discover BICEPS Content == +==SDPi Discover BICEPS Content [DEV-30]== consumer -> provider: GetMdib() consumer <<-- provider: GetMdibResponse(MdDescription, MdState [incl. ContextStates]) diff --git a/asciidoc/plantuml/vol2-figure-dev-34-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-34-sequence.puml index a0e7661..b8fca0c 100644 --- a/asciidoc/plantuml/vol2-figure-dev-34-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-34-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -==SDPi [DEV-34] Announce Network Departure== +==SDPi Announce Network Departure [DEV-34]== ||| group unsecured provider ->> consumer: Bye(Provider UID) diff --git a/asciidoc/plantuml/vol2-figure-dev-35-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-35-sequence.puml index 9c751a5..cec855d 100644 --- a/asciidoc/plantuml/vol2-figure-dev-35-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-35-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -==SDPi [DEV-35] Establish Medical Data Exchange== +==SDPi Establish Medical Data Exchange [DEV-35]== consumer -> provider: Subscribe(Filter, Expiration Time) consumer <<-- provider: SubscribeResponse(Subscription Manager, Expiration Time) diff --git a/asciidoc/plantuml/vol2-figure-dev-36-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-36-sequence.puml index d10c00f..af459c9 100644 --- a/asciidoc/plantuml/vol2-figure-dev-36-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-36-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-36] Publish Medical Data == +==SDPi Publish Medical Data [DEV-36]== consumer <<- provider: Notification(EpisodicMetricReport) diff --git a/asciidoc/plantuml/vol2-figure-dev-37-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-37-sequence.puml index 51c87d7..8ffe1a7 100644 --- a/asciidoc/plantuml/vol2-figure-dev-37-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-37-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-37] Retrieve Medical Data == +==SDPi Retrieve Medical Data [DEV-37]== consumer -> provider: GetMdib() consumer <<-- provider: GetMdibResponse(MdDescription, MdState [incl. ContextStates]) diff --git a/asciidoc/plantuml/vol2-figure-dev-38-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-38-sequence.puml index 2fb89a1..b3129fd 100644 --- a/asciidoc/plantuml/vol2-figure-dev-38-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-38-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -==SDPi [DEV-38] Establish Medical Alert Exchange== +==SDPi Establish Medical Alert Exchange [DEV-38]== consumer -> provider: Subscribe(Filter, Expiration Time) consumer <<-- provider: SubscribeResponse(Subscription Manager, Expiration Time) diff --git a/asciidoc/plantuml/vol2-figure-dev-39-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-39-sequence.puml index fc5b569..1a2e839 100644 --- a/asciidoc/plantuml/vol2-figure-dev-39-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-39-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-39] Publish Medical Alert Update == +==SDPi Publish Medical Alert Update [DEV-39]== consumer <<- provider: Notification(EpisodicAlertReport) diff --git a/asciidoc/plantuml/vol2-figure-dev-40-sequence.puml b/asciidoc/plantuml/vol2-figure-dev-40-sequence.puml index 1b2c007..90dcbf5 100644 --- a/asciidoc/plantuml/vol2-figure-dev-40-sequence.puml +++ b/asciidoc/plantuml/vol2-figure-dev-40-sequence.puml @@ -9,7 +9,7 @@ autonumber participant "$str_somds_consumer" as consumer participant "$str_somds_provider" as provider -== SDPi [DEV-40] Medical Alert Status == +==SDPi Medical Alert Status [DEV-40]== consumer -> provider: GetMdib() consumer <<-- provider: GetMdibResponse(MdDescription, MdState [incl. ContextStates]) diff --git a/asciidoc/plantuml/vol2-figure-xyz.puml b/asciidoc/plantuml/vol2-figure-xyz.puml index af6378f..e0bd7e9 100644 --- a/asciidoc/plantuml/vol2-figure-xyz.puml +++ b/asciidoc/plantuml/vol2-figure-xyz.puml @@ -8,7 +8,7 @@ autonumber participant "$str_sdpi_p_somds_cons" as sdpi_somds_consumer participant "$str_sdpi_p_somds_prov" as sdpi_somds_provider -== SDPi [DEV-23] Announce Network Presence == +==SDPi Announce Network Presence [DEV-23]== ||| group unsecured ' sdpi_somds_provider -> sdpi_somds_consumer: SDC: Hello(EndpointReference, Types, Scopes, [XAddrs]) diff --git a/asciidoc/sdpi-supplement-intro.adoc b/asciidoc/sdpi-supplement-intro.adoc index dc1ce45..6e1a457 100644 --- a/asciidoc/sdpi-supplement-intro.adoc +++ b/asciidoc/sdpi-supplement-intro.adoc @@ -14,7 +14,7 @@ These known limitations include: . The content is scoped per the *_SDPi 1.1 version capabilities specification_* (see https://github.com/IHE/DEV.SDPi/wiki/SDPi-Editorial-Planning-and-Versions#sdpi-version-11-detail---[wiki article "SDPi Version 1.1 (Detail)"]), though future capabilities may be included in a Version Note -. 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 (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 . *Open / Closed Issues tables* -- for SDPi 1.1 the approach for the open / closed issues section has been integrated with the Github Issues that are related to this release; it is expected that this automation will continue to evolve in subsequent releases; . *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_*; an initial approach is provided in <>, with discussion related to how it will be expanded in future versions of the supplement; . *_<> Sections_* (see <>) are included in the specification; however, their use and content will be significantly extended in SDPi 1.x and subsequent versions; @@ -45,8 +45,8 @@ To that end, the supplement includes updates to all (3) IHE DEV TF volumes, incl *TF-1 Profiles* * General overview of the SDPi architectural approach & 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 +* 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 *TF-2 Transactions* diff --git a/asciidoc/sdpi-supplement.adoc b/asciidoc/sdpi-supplement.adoc index 85315d3..7d32f9e 100644 --- a/asciidoc/sdpi-supplement.adoc +++ b/asciidoc/sdpi-supplement.adoc @@ -23,7 +23,7 @@ :ihe_supplement_sdpi_revision: 1.1.0 :ihe_supplement_sdpi_revision_date: {localdatetime} :ihe_supplement_sdpi_revision_label: Trial Implementation -:ihe_supplement_sdpi_publication_month: July 14, 2023 +:ihe_supplement_sdpi_publication_month: July 21, 2023 :ihe_supplement_sdpi_public_comment_submission_deadline: N/A {empty} + @@ -60,7 +60,10 @@ [cols="1,4"] [frame=none,grid=none] |=== -| *Date:* +| *Publication Date:* +| {ihe_supplement_sdpi_publication_month} + +| *Build Date:* | {ihe_supplement_sdpi_revision_date} | *Author:* diff --git a/asciidoc/volume0/tf0-ch-9-copyrights.adoc b/asciidoc/volume0/tf0-ch-9-copyrights.adoc index 8a7fce4..4de57db 100644 --- a/asciidoc/volume0/tf0-ch-9-copyrights.adoc +++ b/asciidoc/volume0/tf0-ch-9-copyrights.adoc @@ -7,7 +7,7 @@ IHE technical documents refer to, and make use of, a number of standards develop [%noheader] [cols="1"] |=== -|Amend section 9.1 by adding the following new Section 9.1.5: +|Amend Section 9.1 by adding the following new Section 9.1.5: |=== [sdpi_offset=5] @@ -33,7 +33,7 @@ IEEE^®^ and IEEE 11073^®^ are registered trademarks of the The Institute of El * 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. +* 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: diff --git a/asciidoc/volume0/tf0-ch-a-actors.adoc b/asciidoc/volume0/tf0-ch-a-actors.adoc index 19ff955..6371474 100644 --- a/asciidoc/volume0/tf0-ch-a-actors.adoc +++ b/asciidoc/volume0/tf0-ch-a-actors.adoc @@ -6,7 +6,7 @@ [%autowidth] [cols="1"] |=== -|Add the following _*new or modified*_ actors to the IHE Technical Frameworks General Introduction https://profiles.ihe.net/GeneralIntro/ch-A.html[Appendix A]. +|Add the following *_new or modified_* actors to the IHE Technical Frameworks General Introduction https://profiles.ihe.net/GeneralIntro/ch-A.html[Appendix A]. |=== //// diff --git a/asciidoc/volume0/tf0-main.adoc b/asciidoc/volume0/tf0-main.adoc index a01fc28..fbc78c7 100644 --- a/asciidoc/volume0/tf0-main.adoc +++ b/asciidoc/volume0/tf0-main.adoc @@ -26,12 +26,12 @@ include::tf0-ch-d-glossary.adoc[] === XML Namespaces -The XML namespace URI that is used by this profile is: `urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1`. +The XML namespace URI that is used by this specification is: `urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1`. -<> lists XML namespaces and prefixes that are used in this profile. +<> lists XML namespaces and prefixes that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant. -.Prefixes and XML namespaces used in this profile. +.Prefixes and XML namespaces used in this specification. [#vol0_table_xml_namespaces,cols="1,5,2",width=100%,] |=== |Prefix |XML Namespace |Specification @@ -42,7 +42,7 @@ The choice of any namespace prefix is arbitrary and not semantically significant |sdpi |urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1 -|This profile +|This specification |wsa |http://www.w3.org/2005/08/addressing diff --git a/asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc b/asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc index c142dab..632b44c 100644 --- a/asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc +++ b/asciidoc/volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc @@ -39,7 +39,7 @@ ADD IEEE: *Remote Control ICS table here* ===== Context Processing NOTE: Context processing pertains to effective utilization of context information like workflow (e.g., orders) info, patient demographics and locations. -A general concept should be described how to cope with contexts in terms of SDPi, i.e. device coupling mechanisms should be described informally in TF-1 and formally in TF-2 (as transaction?). +A general concept should be described how to cope with contexts in terms of SDPi, i.e., device coupling mechanisms should be described informally in TF-1 and formally in TF-2 (as transaction?). ADD IEEE: *Context Processing ICS table here* diff --git a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc index 5d0f7cf..8ada6b4 100644 --- a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc +++ b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc @@ -3,8 +3,8 @@ [#vol1_clause_sdpi_p_profile,sdpi_offset=10] == Service-oriented Device Point-of-care Interoperability – Plug-and-trust (SDPi-P) Profile [#vol1_clause_sdpi_p_profile_reftext,reftext="SDPi-P Profile"] -The SDPi-Plug-and-trust ([[acronym_sdpi_p,SDPi-P]] SDPi-P) profile supports foundational seamless connectivity, information exchange and service invocation as defined in the SDPi architecture detailed in <>. -Whereas the related SDPi profiles for reporting, alerting and external control are explicitly intended to support medical care capabilities, the SDPi-P profile focuses on basic healthcare device interoperability. +The SDPi-Plug-and-trust ([[acronym_sdpi_p,SDPi-P]] SDPi-P) Profile supports foundational seamless connectivity, information exchange and service invocation as defined in the SDPi architecture detailed in <>. +Whereas the related SDPi Profiles for reporting, alerting and external control are explicitly intended to support medical care capabilities, the SDPi-P Profile focuses on basic healthcare device interoperability. All the capabilities defined in SDPi-P are leveraged by and extended in the medically focused profiles. This foundational profile not only supports medical device interoperability ("<>"), providing for “plug-and-play” capabilities, but also with a tightly integrated “trust” framework (see <>). The establishment of a trusted ecosystem of medical and non-medical devices and applications footnote:[Note that SDPi-P supports application interoperability including “Software as a Medical Device” (<>).] begins at the start of discovery and a secure connection. Therefore, the profile's name: <>. @@ -264,7 +264,7 @@ However, the content might also be formalized in a document as opposed to a mess Note that in the case of external control, where a <> is creating and sending content (e.g., patient demographics information) to a <> , the content module creator / consumer roles will be reversed. -A product implementation using this specification may group afrom this profile with actors from a workflow or transport profile to be functional. +A product implementation using this specification may group from this profile with actors from a workflow or transport profile to be functional. The grouping of the content module described in this profile to specific actors is described in more detail in <> or in <>. {empty} + @@ -392,7 +392,7 @@ See <> fo [#vol1_spec_sdpi_p_actor_somds_provider, reftext='SOMDS Provider'] Actor Summary Definition: [none] -. A <> that provides at least one service to the other participant systems. (See <> “SERVICE PROVIDER” definition) +. A <> that provides at least one service to the other participant systems. (See <> “SERVICE PROVIDER” definition.) Every <> is paired with (inherits from) the abstract _<>_ Actor. @@ -420,7 +420,7 @@ Every abstract _<>_ is grouped with (inh A _<>_ can implement both <> and <>. -In the case of a connector implementing a <> , it is able to interact with other <> to either obtain information that is then made available to Non-SOMDS Systems or invoke services that are requested from the external Non-SOMDS Systems. +In the case of a connector implementing a <>, it is able to interact with other <> to either obtain information that is then made available to Non-SOMDS Systems or invoke services that are requested from the external Non-SOMDS Systems. For example, forwarding patient respiratory rate readings to an external “flow sheet” application or invoking a device’s “pause alert audio” service when a clinician indicates they are responding to a physiological alert condition (e.g., high respiratory rate). In the case of a connector implementing a <>, service capabilities for interacting with Non-SOMDS Systems are provided to the other networked <>. @@ -439,12 +439,12 @@ See related discussion at <>_ 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 <>, and <> for additional perspectives and concepts on how SOMDS Connectors may be implemented. +Although the SDPi-P Profile _<>_ 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 <>, and <> for additional perspectives and concepts on how SOMDS Connectors may be implemented. _<>_ 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 _<>s_ in a single consistent way but may support both <> and <> protocols for interacting with healthcare enterprise systems. -_<>_ may also be utilized in other SDPi profiles for medical device information reporting (<>), alerting (<>) and external control (<>). See those profile specifications for detailed usage. In some cases, https://profiles.ihe.net/[IHE profiles] have been defined for supporting integration with Non-SOMDS Systems, such as the V2-based IHE Devices Device to Enterprise Communication (DEC) profile (See <>), or the IHE ITI XDS-I for locating and retrieving images for a specific patient using the XDS.b profile. In these cases, *_profile-specific_* _<>_ adaptors may be specified as well. +_<>_ may also be utilized in other SDPi Profiles for medical device information reporting (<>), alerting (<>) and external control (<>). See those profile specifications for detailed usage. In some cases, https://profiles.ihe.net/[IHE profiles] have been defined for supporting integration with Non-SOMDS Systems, such as the V2-based IHE Devices Device to Enterprise Communication (DEC) profile (See <>), or the IHE ITI XDS-I for locating and retrieving images for a specific patient using the XDS.b profile. In these cases, *_profile-specific_* _<>_ adaptors may be specified as well. [#vol1_clause_sdpi_p_somds_fhir_gateway] ===== SOMDS FHIR Gateway @@ -479,7 +479,7 @@ The <> identifies and specifies the log Since V2 is a message-based protocol, the primary implementation guide logic is defined in <>. Additional specifications for semantic content modules is detailed in <>, including <>. -Generally, the <> supports messaging from a SOMDS environment to V2-enabled systems, utilizing a <> to collect information from <> systems and translate them to V2 messages sent to other Non-SOMDS Systems. There are cases, though, where information may be sent to a SOMDS-based system such as an alert conformation utilizing a DEV-05 (i.e., PCD-05) transaction (see <> below). +Generally, the <> supports messaging from a SOMDS environment to V2-enabled systems, utilizing a <> to collect information from <> systems and translate them to V2 messages sent to other Non-SOMDS Systems. There are cases, though, where information may be sent to a SOMDS-based system such as an alert conformation utilizing a [DEV-05] (i.e., [PCD-05]) transaction (see <> below). [#vol1_clause_sdpi_p_somds_sensor_gateway] ===== SOMDS Sensor Gateway @@ -661,10 +661,12 @@ This generalized model includes (3) system roles: . *Service Providers* -- indicate the capabilities or services that they support, often published to a centralized registry that all participating systems recognize; -. *Service Registry* -- a <> network capability enabling participating systems to *_discover_* services provided by networked systems, as well as information for how a service consumer system can +. *Service Registry* -- a <> network capability enabling participating systems to *_discover_* or "find" services provided by networked systems, as well as information for how a service consumer system can initiate a connection with specific *Service Providers*; + +. *Service Consumer* -- a <> network system that utilizes the capabilities registered by a *Service Provider*. //// -#TODO: ADD --# +#TODO: ADD -- * #why somds# * #distributed registry# @@ -787,7 +789,7 @@ a| *SDPi Supplement Version Note*: This section intentionally left blank for th |=== //// -#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# +#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 @@ -819,7 +821,7 @@ a| *SDPi Supplement Version Note*: This section intentionally left blank for th [#vol1_clause_sdpi_p_use_cases] ==== Use Cases [#vol1_clause_sdpi_p_use_cases_reftext, reftext='SDPi-P Use Cases'] -The SDPi-P profile supports requirements from use cases detailed in <>. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification. +The SDPi-P Profile supports requirements from use cases detailed in <>. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification. //// #TODO: For each of these, add discussion to HOW and WHERE (with links) that the requirements are met. Include a Requirements usage block? CT DEPENDENCY IN SOMDS_PARTICIPANT MEETS THESE REQUIREMENTS# @@ -831,7 +833,7 @@ This use case fully addresses the requirements from <> use case include: * *System Type*: <> supported by SDPi-P <> capabilities (see <>) -* *Service Type*: <> supported by *Consistent Time* profile binding (see <>) +* *Service Type*: <> supported by *Consistent Time* Profile binding (see <>) * *Technical Pre-Conditions*: <> <> are fully supported by SDPi-P * *Scenarios*: <> <> are fully supported by SDPi-P @@ -907,10 +909,10 @@ Specific capabilities supporting the <> use case include: ==== SES General Considerations Requirements from the <>, <>, and related standards should be fully applied to this technical framework element. -For additional guidance, see section <>. +For additional guidance, see Section <>. ==== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Effectiveness Requirements & Considerations @@ -930,7 +932,7 @@ If a <> disables one or more <> General Considerations_ section above. +Additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Security Requirements & Considerations Security is foundational for all interactions between <> Actors, with a clear distinction being made between information that may be exchanged outside of a secure connection (e.g., during network discovery transactions). diff --git a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc index b05cdd0..661e6cd 100644 --- a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc +++ b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc @@ -8,9 +8,9 @@ [cols="1"] |=== a| *SDPi Supplement Version 1.1 Note*: This version of the <> Profile is built upon the foundational <> Profile but does not provide substantially more capabilities. -This is due to the fact that the primary purpose of this specification, namely communication of medical data to accomplish intended medical purposes, requires the completion and integration of two emerging ISO/IEEE standards: <> and <>. +This is due to the fact that the primary purpose of this <> Profile, namely communication of medical data to accomplish intended medical purposes, requires the completion and integration of two emerging ISO/IEEE standards: <> and <>. When these are published *_in 2023_*, their requirements will be integrated into this supplement, with their <> added to <> below. -Many of those requirements will be mapped to the actors and transactions and other specifications in this specification. +Many of those requirements will be mapped to the actors and transactions and other elements in this supplement, including this <> Profile. Additionally, though the <> is defined below and fully specified in <>, the implementation guide for mapping from <> to <> <> remains in development, pushing the specification of the <> to a later version of this supplement. @@ -180,8 +180,8 @@ Every <> is grouped with an <>. Note that optional capabilities for this specification, as specified in <>, may also result in additional requirements for the underlying <> and <>. -This actor shall implement the <> capabilities, receiving information provided by <> systems and publishing them as DEV-01 / PCD-01 Transactions to external DEC Device Observation Consumer (DOC) systems. -If <> is implemented, then this actor will also support the <> capabilities, receiving DEV-01 / PCD-01 Transactions from external DEC Device Observation Reporter (DOR) systems and making them available to other <> systems. +This actor shall implement the <> capabilities, receiving information provided by <> systems and publishing them as [DEV-01] / [PCD-01] Transactions to external DEC Device Observation Consumer (DOC) systems. +If <> is implemented, then this actor will also support the <> capabilities, receiving [DEV-01] / [PCD-01] Transactions from external DEC Device Observation Reporter (DOR) systems and making them available to other <> systems. Note: Not supported are <> systems that only implement the <> and not <> capabilities. Detailed specifications for mapping from <>/<> to <> V2 / DEC transactions are provided in <>. @@ -258,7 +258,7 @@ Note that this specification extends the concepts established in the base <>. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification. +The SDPi-R Profile supports requirements from use cases detailed in <>. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification. ===== <> (<>) @@ -314,16 +314,16 @@ Once published, their requirements will be integrated into this supplement, with |=== -For additional guidance, see section <>. +For additional guidance, see Section <>. ==== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Effectiveness Requirements & Considerations -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Security Requirements & Considerations -No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile (see <>), and those specified in the _<> General Considerations_ section above. +No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see <>), and those specified in the _<> General Considerations_ Section above. [#vol1_clause_sdpi_r_cross_profile_considerations] === SDPi-R Cross Profile Considerations diff --git a/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc b/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc index 4d0c811..c4ced2b 100644 --- a/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc +++ b/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc @@ -12,10 +12,10 @@ Additionally, since the primary purpose of this specification is the communicati When this new standard is published *_in late 2023 or early 2024_*, its requirements will be integrated into this supplement, with its <> added to <>. 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 <> standards, particularly in association with completing the Alert <> standard <>. +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 <> standards, particularly in association with completing the Alert <> standard <>. As a result, the completion of these two transactions has been deferred to a subsequent version of the supplement. -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. +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 <> is defined below and fully specified in <>. Also in development is <> <> support for medical alerting (e.g., definition of a <> DeviceAlert resource); however, that will not be completed until 2024 or beyond. @@ -95,19 +95,19 @@ image::../images/vol1-diagram-sdpi-a-actor.svg[] | <> (_deferred_) | Responder | R ^(See^ ^Note^ ^1)^ -| DEV-41 Deferred to SDPi 2.0 +| [DEV-41] Deferred to SDPi 2.0 // <> | <> (_deferred_) | Initiator | R ^(See^ ^Note^ ^1)^ -| DEV-42 Deferred to SDPi 2.0 +| [DEV-42] Deferred to SDPi 2.0 // <> | <> (_deferred_) | Responder | R -| DEV-43 Deferred to SDPi 2.0 +| [DEV-43] Deferred to SDPi 2.0 // <> .6+| <> @@ -129,19 +129,19 @@ image::../images/vol1-diagram-sdpi-a-actor.svg[] | <> (_deferred_) | Initiator | R ^(See^ ^Note^ ^1)^ -| DEV-41 Deferred to SDPi 2.0 +| [DEV-41] Deferred to SDPi 2.0 // <> | <> (_deferred_) | Responder | R ^(See^ ^Note^ ^1)^ -| DEV-42 Deferred to SDPi 2.0 +| [DEV-42] Deferred to SDPi 2.0 // <> | <> (_deferred_) | Initiator | R -| DEV-43 Deferred to SDPi 2.0 +| [DEV-43] Deferred to SDPi 2.0 // <> .4+| <> ^(See^ ^Note^ ^2)^ @@ -163,14 +163,14 @@ image::../images/vol1-diagram-sdpi-a-actor.svg[] | <> (_deferred_) | Initiator | O -| dev-43 Deferred to SDPi 2.0 +| [DEV-43] Deferred to SDPi 2.0 // <> 5+<| Note 1: Transaction is required if <> is supported. -Note 2: By default, the <> acts as a <>, initiating DEV-04 transactions when they are received from <>s. -If the gateway supports <>, then it also acts as a <> and accepts inbound DEV-04 transactions from ACM Alert Reporters. +Note 2: By default, the <> acts as a <>, initiating [DEV-04] transactions when they are received from <>s. +If the gateway supports <>, then it also acts as a <> and accepts inbound [DEV-04] transactions from ACM Alert Reporters. In this case, the gateway will support both "Initiator & Responder" for these transactions. |=== @@ -242,7 +242,7 @@ Actor Summary Definition: [none] . A <> grouped actor that supports the bi-directional exchange of medical alert information with non-SOMDS systems and applications using IHE Alert Communication Management (ACM) transactions. -This a is designed to exchange medical device alert information to external non-<> systems using the <> V2-based Alert Communication Management (ACM) profile transactions. +This a is designed to exchange medical device alert information to external non-<> systems using the <> V2-based Alert Communication Management (ACM) Profile transactions. Every <> is grouped with an <> to enable <>-based connectivity. This actor inherits all the capabilities of the paired <>. @@ -252,14 +252,14 @@ Transactions enabled for this actor are identified in <> standards (<> and <>), as well as the <> standards <> and <> (Alert <>). -This actor shall implement the <> capabilities, receiving alert information provided by <> systems and publishing them as DEV-04 / PCD-04 Transactions to external ACM Alert Manager (AM) systems. -If <> is implemented, then this actor will also support the <> capabilities, receiving DEV-04 / PCD-04 Transactions from external ACM Device Observation Reporter (DOR) systems and making them available to other <> systems. +This actor shall implement the <> capabilities, receiving alert information provided by <> systems and publishing them as [DEV-04] / [PCD-04] Transactions to external ACM Alert Manager (AM) systems. +If <> is implemented, then this actor will also support the <> capabilities, receiving [DEV-04] / [PCD-04] Transactions from external ACM Device Observation Reporter (DOR) systems and making them available to other <> systems. Note: Not supported are <> systems that only implement the <> and not <> capabilities. -Detailed specifications for mapping from <>/<> to <> V2 / ACM DEV-04/PCD-04 transactions are provided in <>. +Detailed specifications for mapping from <>/<> to <> V2 / ACM [DEV-04]/[PCD-04] transactions are provided in <>. NOTE: This actor is not intended to play the role of an ACM Alert Manager. -If DEV-04 transactions are received by the gateway, they will be simply mapped to <>/<> semantics and provided to <> systems. +If [DEV-04] transactions are received by the gateway, they will be simply mapped to <>/<> semantics and provided to <> systems. If a <> is being created, it may incorporate both <> and <> Actors, both receiving and publishing alerts to external ACM-based systems. @@ -280,7 +280,7 @@ As stated elsewhere, the completion of the <> standar *_The sequence diagram below for delegation is provided for informative purposes only and will be finalized when the IEEE standard and this profile option are completed._* This option will enable <> systems to safely and reliably transfer or "delegate" audible annunciation of alert conditions to another system. -This option will enable both the DEV-41 <> and DEV-42 <> transactions. +This option will enable both the <> [DEV-41] and <> [DEV-42] transactions. |=== @@ -312,7 +312,7 @@ include::../plantuml/vol1-figure-sdpi-a-delegation-example-sequence-diagram.puml a| *SDPi Supplement Version Note*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable <> systems to safely and reliably receive from <> systems user (clinician) acknowledgement of previously reported alert conditions. -This option will enable the DEV-43 <> transaction. +This option will enable the <> [DEV-43] transaction. |=== @@ -326,8 +326,8 @@ This option will enable the DEV-43 <> systems to receive DEV-04/PCD-04 transactions from an ACM Alert Manager and then act as a <> to communicate the signals to <> systems -This option will enable the <> to respond to DEV-38 <> and DEV-40 <> transactions, and to initiate DEV-39 <> transactions. +This option will enable <> systems to receive [DEV-04]/[PCD-04] transactions from an ACM Alert Manager and then act as a <> to communicate the signals to <> systems +This option will enable the <> to respond to <> [DEV-38] and <> [DEV-40] transactions, and to initiate <> [DEV-39] transactions. |=== @@ -366,7 +366,8 @@ Note that this specification extends the concepts established in the base <>. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification. +The SDPi-A Profile supports requirements from use cases detailed in <>. +The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this SDPi-A Profile. ===== <> (<>) @@ -420,16 +421,16 @@ Specific capabilities supporting the <> use case include: ==== SES General Considerations Requirements from the <>, <>, and related standards should be fully applied to this technical framework element. -For additional guidance, see section <>. +For additional guidance, see Section <>. ==== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Effectiveness Requirements & Considerations -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Security Requirements & Considerations -No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile (see <>), and those specified in the _<> General Considerations_ section above. +No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see <>), and those specified in the _<> General Considerations_ Section above. // 12.6 === SDPi-A Cross Profile Considerations diff --git a/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc b/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc index 3dee123..3194dd7 100644 --- a/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc +++ b/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc @@ -7,7 +7,7 @@ [%autowidth] [cols="1"] |=== -a| *SDPi Supplement Version Note*: This SDPi-xC (External Control) profile section is generally out-of-scope for the SDPi 1.1 version (see https://github.com/IHE/DEV.SDPi/wiki/SDPi-Editorial-Planning-and-Versions#sdpi-version-11-detail---[wiki article "SDPi Version 1.1 (Detail)"]); 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 2023 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| *SDPi Supplement Version Note*: This SDPi-xC (External Control) Profile Section is generally out-of-scope for the SDPi 1.1 version (see https://github.com/IHE/DEV.SDPi/wiki/SDPi-Editorial-Planning-and-Versions#sdpi-version-11-detail---[wiki article "SDPi Version 1.1 (Detail)"]); 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 2023 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). |=== @@ -48,26 +48,26 @@ image::../images/vol1-diagram-sdpi-xc-actor.svg[] .^| <> (_deferred_) .^| Responder .^| R -| DEV-44 Deferred to SDPi 3.0 or later +| [DEV-44] Deferred to SDPi 3.0 or later // <> | <> (_deferred_) | Responder | R -| DEV-45 Deferred to SDPi 3.0 or later +| [DEV-45] Deferred to SDPi 3.0 or later // <> .2+| <> .^| <> (_deferred_) .^| Initiator .^| R -| DEV-44 Deferred to SDPi 3.0 or later +| [DEV-44] Deferred to SDPi 3.0 or later // <> | <> (_deferred_) | Initiator | R -| DEV-45 Deferred to SDPi 3.0 or later +| [DEV-45] Deferred to SDPi 3.0 or later // <> |=== @@ -168,7 +168,7 @@ Note that this specification extends the concepts established in the base <>, <>, and related standards should be fully applied to this technical framework element. -For additional guidance, see section <>. +For additional guidance, see Section <>. ==== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Effectiveness Requirements & Considerations -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Security Requirements & Considerations -No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile (see <>), and those specified in the _<> General Considerations_ section above. +No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see <>), and those specified in the _<> General Considerations_ Section above. === SDPi-xC Cross Profile Considerations No additional cross profile considerations have been identified. diff --git a/asciidoc/volume1/tf1-ch-2-overview.adoc b/asciidoc/volume1/tf1-ch-2-overview.adoc index 04e7801..c5657fd 100644 --- a/asciidoc/volume1/tf1-ch-2-overview.adoc +++ b/asciidoc/volume1/tf1-ch-2-overview.adoc @@ -13,7 +13,7 @@ It is intended to amend a new IHE DEV Technical Framework (TF), that covers the As a result of these basic changes in the scope and organization of the IHE DEV domain, some additional TF sections have been proposed to help the community understand how these technical specifications are integrated. For example, . Section(s) for General IHE Devices architecture, use contexts, and (4) <> functions -- Connecting, Reporting, Alerting, and Controlling (external) -. Section addressing "What is a device?" (aligned with a similar topic within the joint IHE-HL7 Gemini project); especially relevant given the differences between <> and <> as well as the increasing prevalence of <> applications. (See https://confluence.hl7.org/x/Iw7xB["Paper: What is a device?"] for additional background) +. Section addressing "What is a device?" (aligned with a similar topic within the joint IHE-HL7 Gemini project); especially relevant given the differences between <> and <> as well as the increasing prevalence of <> applications. (See https://confluence.hl7.org/x/Iw7xB["Paper: What is a device?"] for additional background.) These general concepts will help the technical framework reader understand the broader context into which the profile specifications are intended to be implemented. @@ -54,7 +54,7 @@ In this version, the content is added as 2.3.1, and then the profiles as 2.3.10 [#vol1_clause_sdpi_overview_framework] ==== Service-oriented Device Point-of-care Interoperability (SDPi) – Overview & Framework -The Service-oriented Device Point-of-care Interoperability (SDPi) profiles are built upon a foundation of standards and profiles from <>, <>, IHE and other organizations. An overview of the profiles and their relationships is provided in <>. +The Service-oriented Device Point-of-care Interoperability (SDPi) Profiles are built upon a foundation of standards and profiles from <>, <>, IHE and other organizations. An overview of the profiles and their relationships is provided in <>. .IHE SDPi Profiles & Foundational Standards [#figure_sdpi_profiles_foundational_standards] @@ -66,7 +66,7 @@ There is a particular challenge with SDPi profiling of <> that resu . *__How to represent a <>-based architecture supporting an interactive <> device-to-device (multi-way, M:N) interoperability specification using established IHE technical framework constructs? __* NOTE: The arrows indicate reference relationships and not specializations. -For example, The three SDPi-R, -A and -xC profiles refer to the foundational SDPi-P profile. +For example, The three SDPi-R, -A and -xC Profiles refer to the foundational SDPi-P profile. This is achieved by the use of IHE "grouped actors". Or IHE "gateway" actors include mappings to the foundational, non-SDC standards. @@ -78,10 +78,10 @@ The above figure illustrates how this balance was achieved, including: .. By separating SDPi into four separate but integrated profiles, the complexity of the <> system-to-system interactions + the optionality of real-world systems is better managed. . *Gateway Actors* [none] -.. The profiles are built upon a solid foundation of existing standards from various <>s and that are currently implemented for device information exchange, albeit in different use contexts such as healthcare enterprise / <> integration. +.. The Profiles are built upon a solid foundation of existing standards from various <>s and that are currently implemented for device information exchange, albeit in different use contexts such as healthcare enterprise / <> integration. .. The actors provide defined mappings from SDPi transactions and semantics to those of other standards and standards profiles (e.g., IHE DEC or ACM). .. Gateways can be bi-directional, receiving information from non-SDPi enabled systems, such as patient demographics information from an <>. -.. For a more complete "Big Picture" perspective, see the discussion in section <> below. +.. For a more complete "Big Picture" perspective, see the discussion in <>. . *PKPs for Medical Purposes* [none] .. A unique aspect of the IEEE 11073 <> family of standards are the inclusion of the <> standards that advance <> "medical" interoperability. @@ -89,7 +89,7 @@ The above figure illustrates how this balance was achieved, including: .. These standards represent shared or consensus risk management requirements (e.g., risk mitigations) that together address how to implement <> interoperable *medical device* technologies. .. The diagram illustrates how the <> Core Standards provide for basic healthcare connectivity; whereas the <> standards add a requirements layer for devices that have a *_medical interoperability purpose_*. -"**PRAC**tical" Device Interoperability may be a bit "cute"; however, it does map to the (4) profiles, which together provide a practical, pragmatic way toward genuine <> interoperability: +"**PRAC**tical" Device Interoperability may be a bit "cute"; however, it does map to the (4) Profiles, which together provide a practical, pragmatic way toward genuine <> interoperability: [none] . P -> SDPi-Plug-and-trust @@ -98,27 +98,27 @@ The above figure illustrates how this balance was achieved, including: . C -> SDPi-xControl It should be noted that the _primary use context_ for SDPi-enabled technologies is high acuity points of care, namely Operating Rooms, ICU beds, emergency beds, etc. -Within this context, the core focus of these profiles is direct <> interactions at the point of care. +Within this context, the core focus of these Profiles is direct <> interactions at the point of care. Gateway actors provide integration with systems beyond the scope of the acute bedside context, typically though not necessarily using other protocols. This <> is differentiated with the current implementation reality where devices use proprietary protocols to talk with their manufacturer's gateway server, requiring a level of indirection (server-to-server integration), and the attendant performance, quality and capability limitations. -See section <> below for additional conceptual overview information on the conceptual foundations of the <> standards. +See <> below for additional conceptual overview information on the conceptual foundations of the <> standards. [sdpi_offset=10] ==== Service-oriented Device Point-of-care Interoperability - Plug-and-trust (SDPi-P) Profile -Within the framework of the SDPi architecture, the Plug-and-Trust ([[acronym_sdpi_p,SDPi-P]] SDPi-P) profile provides for *_secure plug-and-play connectivity_* between all actors. +Within the framework of the SDPi architecture, the Plug-and-Trust ([[acronym_sdpi_p,SDPi-P]] SDPi-P) Profile provides for *_secure plug-and-play connectivity_* between all actors. The primary use context is acute care beds (e.g., ICU, operating room, emergency department), though it may be used in other healthcare contexts. This specification provides for plug-and-trust (secured) communication for healthcare devices, systems and applications, regardless of whether they are "regulated" medical devices. -That said, the SDPi-P profile fully supports the safety and security requirements specified in the <> Base <> standard. -Other SDPi profiles provide direct support for _interoperable medical systems_. +That said, the SDPi-P Profile fully supports the safety and security requirements specified in the <> Base <> standard. +Other SDPi Profiles provide direct support for _interoperable medical systems_. Taking this approach allows non-medical technology to interact with other SDPi-enabled systems but without the added burden of having to support the more rigorous requirements associated with technology intended for a medical purpose (e.g., additional risk control mitigation measures). -This baseline profile supports the _*core*_ functionality needed by all participating systems. +This baseline profile supports the *_core_* functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., "ensemble context" management). [sdpi_offset=11] ==== Service-oriented Device Point-of-care Interoperability - Reporting (SDPi-R) Profile -The SDPi Reporting profile builds on the basic <> capabilities of the <> profile, but adds the requirements to fully support *_medical data reporting_*. +The SDPi Reporting Profile builds on the basic <> capabilities of the <> profile, but adds the requirements to fully support *_medical data reporting_*. To that end, this specification fully supports the safety and security requirements in the <> metric reporting <> standard. The profile supports core medical data reporting functionality needed by all participating systems. @@ -126,7 +126,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 <> capabilities of the <> profile, but adds the requirements to fully support *_medical alerting_*. +The SDPi Alerting Profile builds on the basic <> capabilities of the <> profile, but adds the requirements to fully support *_medical alerting_*. To that end, this specification implements the safety and security requirements of the <> alert <> standard (expected to be completed in 2023). The profile supports core medical alerting functionality needed by all participating systems. @@ -143,11 +143,11 @@ Profile options are provided for additional capabilities that may be required to [%autowidth] [cols="1"] |=== -a| *SDPi Supplement Version Note*: For SDPi 1.1, the SDPi-xC profile is provided for completeness and to show the general direction of the family of SDPi profiles. +a| *SDPi Supplement Version Note*: For SDPi 1.1, the SDPi-xC Profile is provided for completeness and to show the general direction of the family of SDPi Profiles. It is *_not part of the capabilities specified for 1.1_* and even basic controls will not be added until SDPi 2.0 or later. |=== -The SDPi External Control profile builds on the basic <> capabilities of the <> profile, but adds support for *_medical device external control capabilities_*. +The SDPi External Control Profile builds on the basic <> capabilities of the <> profile, but adds support for *_medical device external control capabilities_*. For example, the ability to have a system initiate a blood pressure reading, or set a breath rate, or titrate an infusion pump's delivery rate. Given the significant risks associated with allowing device-external control functions in a network of <> systems, this specification implements the safety and security requirements of the <> external control <> standard (in development, anticipated in 2023 or later). diff --git a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc index 6edf81f..9a7b87b 100644 --- a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc +++ b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc @@ -57,7 +57,7 @@ Last accessed 2022.10.04.], some general observations will help understand the v . ; . ; . ; -. > section below.>. +. > Section below.>. //// #TODO: ADD INTEROPERABILITY PATHS EXAMPLE VIA A TABLE (VS. LINES THROUGH GRAPHIC)# @@ -85,7 +85,7 @@ One of the key challenges for implementing this standard, though, is what might This is the technology "hand off" space between the left side of the lifecycle -- Design and development phase, where key responsibility is by each of the "Accountable Manufacturer" organizations, and the right side of the lifecycle -- Implementation phase & Clinical use phase, where key responsibility is on the Accountable Healthcare Delivery Organization (HDO). Though this reads well in the standards and the model organizes everything in a clear fashion, operationalizing this in real world use remains a Sisyphean effort, primarily due to the amount of expertise, time and resources needed to effectively implement the SES standards as part of normal operating business in HDOs. -To address this <> implementation problem, the SDPi profiles: +To address this <> implementation problem, the SDPi Profiles: . Leverage the ISO/IEEE 11073-1070x <> standards, which represent a consensus standard for risk management of technologies that are implemented in that left-right gap on the Temple model; . <> tables from each of these <> standards is included in <> of this specification, with indication as to whether, how and where each requirement is addressed; @@ -113,7 +113,7 @@ Especially when requirements from the <> standards are included in Note: When the <> standards are integrated into this specification, then specific requirements will be directly linked to these <> Considerations sections. |=== -Given the forgoing discussion in section <>, a standardized template is defined for addressing <> requirements as appropriate, including within the scope of profiles, actors, transactions, and content modules. +Given the forgoing discussion in <>, a standardized template is defined for addressing <> requirements as appropriate, including within the scope of profiles, actors, transactions, and content modules. The content in the following sections should be included and then specialized as appropriate for the associated technical framework element. //// @@ -132,23 +132,23 @@ NOTE: This section includes guidance and requirements that are not further speci Requirements from the <>, <>, and related standards should be fully applied to this technical framework element. -For additional guidance, see section <>. +For additional guidance, see Section <>. ==== Safety Requirements & Considerations NOTE: This section includes guidance and requirements that are focused on unique *_Safety_* requirements associated with associated technical framework element. Note: a simple definition of safety within the context of risk management is "freedom from unacceptable harm" (see https://81001.org/concept/safety[81001.org/safety]) -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Effectiveness Requirements & Considerations NOTE: This section includes guidance and requirements that are focused on unique *_Effectiveness_* requirements associated with associated technical framework element. Note: in the context of risk management key properties, effectiveness is the ability to perform the intended use (see https://81001.org/concept/effectiveness[81001.org/effectiveness]) -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ==== Security Requirements & Considerations NOTE: This section includes guidance and requirements that are focused on unique *_Security_* requirements associated with associated technical framework element. In the context of risk management key properties, security is a state where information and systems are protected from unauthorized activities to a degree that the related risks to confidentiality, integrity, and availability are maintained at an acceptable level throughout the lifecycle (see https://81001.org/concept/security[81001.org/security]) -No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile, and those specified in the _<> General Considerations_ section above. +No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile, and those specified in the _<> General Considerations_ Section above. === Use Cases, MBSE Requirements Modeling & SysML 2.0 @@ -170,7 +170,7 @@ a| *SDPi Supplement Version Note*: This section intentionally left blank for th <>'s Systems Modeling Language 2.0 (see <> and <>), provides extended support for requirements modeling that not only provides the foundation for MBSE's Requirements Modeling, but also a computable specification that enables automated verification (e.g., using "Verification Cases"). //// -#TODO: Add reference to SysML 2.0 section 7.20 Requirements & 7.23 Verification Cases# +#TODO: Add reference to SysML 2.0 Section 7.20 Requirements & 7.23 Verification Cases# #TODO: Add reference to Hanging Gardens Framework ... use case requirements are the top level# @@ -180,12 +180,12 @@ a| *SDPi Supplement Version Note*: This section intentionally left blank for th [#vol1_clause_sdpi_requirements_modeling_integration] === SDPi Requirements Modeling & Integration -As pointed out above, requirements interoperability (RI) based on robust model-based metadata is a core, innovative aspect of this SDPi profiles specification. -Given the ultimate intent to realize this description as a _Model Centric (MC) single-source-of-truth, computable, simulatable, verifiable and validatable system of systems interoperability specification_, and recognizing that it will take a significant transition period from a document-centric approach to a model-centric approach, a simplified requirements model is provided below but is aligned with the <> section 7.20 Requirements language. -Of course, that specification provides for significantly more detailed and complext modeling, the general constructs may be used in this document to start the transition toward that model. +As pointed out above, requirements interoperability (RI) based on robust model-based metadata is a core, innovative aspect of this SDPi Profiles specification. +Given the ultimate intent to realize this description as a _Model Centric (MC) single-source-of-truth, computable, simulatable, verifiable and validatable system of systems interoperability specification_, and recognizing that it will take a significant transition period from a document-centric approach to a model-centric approach, a simplified requirements model is provided below but is aligned with the <> Section 7.20 Requirements language. +Of course, that specification provides for significantly more detailed and complex modeling, the general constructs may be used in this document to start the transition toward that model. Note that SysML 2.0 also better supports model interoperability (tool-independent model exchange) and _<>_ (see https://en.wikipedia.org/wiki/Model-based_systems_engineering[MBSE Wikipedia article and references]), as well as the <> for an overview presentation of MBSE, MedTech system V&V, and IHE Conformity Assessment. -It should be further noted that though conformity testing aspects are beyond this revision of the SDPi specification, the modeling constructs used below will also be integrated with <> section 7.23 Verification Cases, to provide for advanced V&V of interoperable system components and entire systems of products. +It should be further noted that though conformity testing aspects are beyond this revision of the SDPi specification, the modeling constructs used below will also be integrated with <> Section 7.23 Verification Cases, to provide for advanced V&V of interoperable system components and entire systems of products. [#vol1_clause_sdpi_requirements_core_model] ==== SDPi Requirements Core Model @@ -233,7 +233,7 @@ Each type is a source of requirements that are explicitly identified and formali | SES | | sdpi_requirement_ses -| See SES section <> +| See SES Section <> | Tech Feature | @@ -260,7 +260,7 @@ In that case, the general rule is: For example, in TF-2 Transactions, each transaction section is paired with a message transport section in <>; however, future versions of the specification may provide options for alternative transports. In this case, the actual transaction definition will remain unchanged, but the bindings to transport messages and services would change. -Given the rule above, bindings are made in the current TF-2 Appendix A MDPWS profile pointing backward (or upward!) to the transaction requirements that they satisfy. +Given the rule above, bindings are made in the current TF-2 Appendix A MDPWS specification pointing backward (or upward!) to the transaction requirements that they satisfy. There are no bindings in the opposite direction. Taking this approach, a new transport appendix could be added in the future without impacting the core transaction specifications. diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-60601-1-8.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-60601-1-8.adoc index 77f1af9..bcbeced 100644 --- a/asciidoc/volume1/use-cases/tf1-ch-c-60601-1-8.adoc +++ b/asciidoc/volume1/use-cases/tf1-ch-c-60601-1-8.adoc @@ -18,7 +18,7 @@ The other models are anticipated for subsequent versions. • Cannot rely on it for alarm signaling as a risk control -• Optional support operator alarm management* response locally +• Optional support operator alarm management response locally • Example -- patient remote display, hallway display, one-way pager @@ -31,7 +31,7 @@ NOTE: CDIS is not recognized in 60601-1-8, however it is implemented in practise • Cannot rely on it for alarm signaling as a risk control -• Optional support operator alarm management* response locally and remotely +• Optional support operator alarm management response locally and remotely • Example –- two-way pager (open loop) @@ -179,7 +179,7 @@ NOTE: NOTE 1 The parts of a DISTRIBUTED ALARM SYSTEM can be widely separated in NOTE: NOTE 2 A DISTRIBUTED ALARM SYSTEM is intended to notify OPERATORS of the existence of an ALARM CONDITION. -NOTE: NOTE 3 For the purposes of this document, technical confirmation means that each element of a DISTRIBUTED ALARM SYSTEM confirms or guarantees the successful delivery of the ALARM CONDITION to the next element or appropriate TECHNICAL ALARM CONDITIONS are created as described in 6.11.2.2.1. +NOTE: NOTE 3 For the purposes of this document, technical confirmation means that each element of a DISTRIBUTED ALARM SYSTEM confirms or guarantees the successful delivery of the ALARM CONDITION to the next element or appropriate TECHNICAL ALARM CONDITIONS are created as described in clause 6.11.2.2.1 of <>. {empty} + @@ -192,7 +192,7 @@ Examples include: - EXAMPLE 1 – A central station - EXAMPLE 2 – An electronic record-keeping device - EXAMPLE 3 – Remote viewing from home or office -- EXAMPLE 4 – Bed-to-bed viewing of ALARM CONDITIONS (e.g. one nurse for two beds). +- EXAMPLE 4 – Bed-to-bed viewing of ALARM CONDITIONS (e.g., one nurse for two beds). - EXAMPLE 5 – Transmission of ALARM CONDITIONS to pagers, cell phones, hand-held computers, etc. ====== CDAS - DISTRIBUTED ALARM SYSTEM WITH OPERATOR CONFIRMATION @@ -251,7 +251,7 @@ A similar configuration might be provided for other DISTRIBUTED ALARM SYSTEMS, f Care is needed in the design of a CDAS when there is a non-homogenous set of SOURCES. The logic (REDIRECTION and ESCALATION) behind the processing of RESPONSIBILITY UNDEFINED can become very complex and needs to take into account how each SOURCE responds to the resulting states. -These complex systems can inadvertently cause ALARM FLOOD or ‘lost’ ALARM CONDITIONS (i.e. no assigned COMMUNICATOR). +These complex systems can inadvertently cause ALARM FLOOD or ‘lost’ ALARM CONDITIONS (i.e., no assigned COMMUNICATOR). Such a configuration would not be expected in ME EQUIPMENT without a DISTRIBUTED ALARM SYSTEM. For example, an anaesthesia workstation, for which an OPERATOR is normally present during all PATIENT care, would not be expected to provide these functions. diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-use-case-ddes.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-use-case-ddes.adoc index e2c66ad..04e9c5f 100644 --- a/asciidoc/volume1/use-cases/tf1-ch-c-use-case-ddes.adoc +++ b/asciidoc/volume1/use-cases/tf1-ch-c-use-case-ddes.adoc @@ -25,7 +25,7 @@ image::../images/vol1-diagram-use-case-ddes-tech-view.svg[] *And* All devices report either a device label and/or location -*And* A <> Service is associated with a specific set of device labels, and/or location(s) (i.e. devices in scope) +*And* A <> Service is associated with a specific set of device labels, and/or location(s) (i.e., devices in scope) [#vol1_clause_appendix_c_use_case_ddes_scenarios] ==== Scenarios @@ -46,7 +46,7 @@ image::../images/vol1-diagram-use-case-ddes-tech-view.svg[] *Given* The <> Service is exporting data to the EHR -*Then* The <> Service will comply with all IHE DEV DEC profile DOR actor functional and test requirements +*Then* The <> Service will comply with all IHE DEV / PCD DEC Profile DOR actor functional and test requirements ===== Scenario: <> {var_use_case_id}.3 - <> Service has a failure diff --git a/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc b/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc index b1ff111..d331725 100644 --- a/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc +++ b/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc @@ -81,7 +81,7 @@ a| *SDPi Supplement Version Note*: This section intentionally left blank for th // [mdi_use_case#use_case_stad,actors='actor_somds_provider actor_somds_consumer',figure=vol2_figure_dev_24_probe_sequence,messages='message_announce_network_presence'] -// FROM TF-2 DEV-24 Transaction document +// FROM TF-2 [DEV-24] Transaction document // [sdpi_transaction#transaction_dev_24,actors='actor_somds_provider actor_somds_consumer',figure=vol2_figure_dev_24_probe_sequence,messages='message_announce_network_presence'] ==== Application of ISO/IEC 60601-1-8 Concepts & Definitions diff --git a/asciidoc/volume2/connect-time-algorithm/tf2-ch-a-mdpws-connect-time-algorithm.adoc b/asciidoc/volume2/connect-time-algorithm/tf2-ch-a-mdpws-connect-time-algorithm.adoc index 3fce525..d964373 100644 --- a/asciidoc/volume2/connect-time-algorithm/tf2-ch-a-mdpws-connect-time-algorithm.adoc +++ b/asciidoc/volume2/connect-time-algorithm/tf2-ch-a-mdpws-connect-time-algorithm.adoc @@ -11,7 +11,7 @@ In order to suppress concurrent connection attempts, in the ad-hoc mode a <> is reassigned an IP address, or 3. when a <> changes its <>. -IP address reassignment can occur because of intended or unintended interruptions in the network connection, network reconfiguration during operation (e.g. by plugging of Ethernet switches), or other causes. +IP address reassignment can occur because of intended or unintended interruptions in the network connection, network reconfiguration during operation (e.g., by plugging of Ethernet switches), or other causes. It is assumed that <> are connected to an IP network that uses dynamic IP address assignment managed by a DHCP server. -The use of static IP addresses is discouraged as it may lead to IP address conflicts, and hence severe communication disruption, in case of network reconfiguration during operation (e.g. by plugging of Ethernet switches). +The use of static IP addresses is discouraged as it may lead to IP address conflicts, and hence severe communication disruption, in case of network reconfiguration during operation (e.g., by plugging of Ethernet switches). .R2000 [sdpi_requirement#r2000,sdpi_req_level=should] @@ -59,7 +59,7 @@ include::../dev-a-default-expected-actions.adoc[] [#vol2_clause_appendix_mdpws_dev_23_recurring_hello,sdpi_level=+1] ====== Recurring Hello -In addition to the Hello message trigger events defined in <>, recurring Hello messages are needed to decrease the likelihood of missed discovery messages in case of network topology changes during operation, e.g. when operational networks are extended by plugging switches (together) at runtime. +In addition to the Hello message trigger events defined in <>, recurring Hello messages are needed to decrease the likelihood of missed discovery messages in case of network topology changes during operation, e.g., when operational networks are extended by plugging switches (together) at runtime. .R2001 [sdpi_requirement#r2001,sdpi_req_level=shall] @@ -69,7 +69,7 @@ A <> shall periodically send Hello messag .Notes [%collapsible] ==== -The random interval between 60 seconds and 120 seconds aims to prevent <>s from congesting the network by sending recurring Hello messages at the same time. +NOTE: The random interval between 60 seconds and 120 seconds aims to prevent <>s from congesting the network by sending recurring Hello messages at the same time. ==== **** diff --git a/asciidoc/volume2/dev-23/tf2-dev-23.adoc b/asciidoc/volume2/dev-23/tf2-dev-23.adoc index 58c0809..5d7ecb2 100644 --- a/asciidoc/volume2/dev-23/tf2-dev-23.adoc +++ b/asciidoc/volume2/dev-23/tf2-dev-23.adoc @@ -16,7 +16,7 @@ include::tf2-dev-23-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -35,7 +35,7 @@ include::tf2-dev-23-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_23_sequence, target=puml-dev-23-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-23-sequence.puml[] @@ -48,7 +48,7 @@ include::../../plantuml/vol2-figure-dev-23-sequence.puml[] The corresponding message for this transaction is called _{var_label_dev_23_message_hello}_. Note that the {var_label_dev_23_message_hello} message described in this clause is a generic/abstract concept that can be implemented differently. -It should not be confused with actual transport message specifications like, e.g. the WS-Discovery Hello message as described in <>. +It should not be confused with actual transport message specifications like, e.g., the WS-Discovery Hello message as described in <>. The {var_label_dev_23_message_hello} is a multicast message that is sent from each <> to all listening <>s (zero to many). Limited but sufficient information is provided with the message to enable <>s to determine if they are interested in connecting with the <> discovering additional information. diff --git a/asciidoc/volume2/dev-24/tf2-ch-a-mdpws-dev-24.adoc b/asciidoc/volume2/dev-24/tf2-ch-a-mdpws-dev-24.adoc index 42fe26f..648e2bf 100644 --- a/asciidoc/volume2/dev-24/tf2-ch-a-mdpws-dev-24.adoc +++ b/asciidoc/volume2/dev-24/tf2-ch-a-mdpws-dev-24.adoc @@ -59,10 +59,10 @@ Therefore, in order to prevent the network congestion from Probe / ProbeMatch me **** A <> should not periodically send Probe messages. -.Note +.Notes [%collapsible] ==== -If Probe messages are sent periodically, a rationale needs to be provided, since <>s send Hello messages periodically. +NOTE: If Probe messages are sent periodically, a rationale needs to be provided, since <>s send Hello messages periodically. ==== **** @@ -71,10 +71,10 @@ If Probe messages are sent periodically, a rationale needs to be provided, since **** A <> may re-send Probe messages if demanded by a dedicated user interaction. -.Note +.Notes [%collapsible] ==== -A dedicated user interaction can be a button press on a <>'s display or any other manual activation. +NOTE: A dedicated user interaction can be a button press on a <>'s display or any other manual activation. ==== **** diff --git a/asciidoc/volume2/dev-24/tf2-dev-24.adoc b/asciidoc/volume2/dev-24/tf2-dev-24.adoc index 26c05f8..dab9ded 100644 --- a/asciidoc/volume2/dev-24/tf2-dev-24.adoc +++ b/asciidoc/volume2/dev-24/tf2-dev-24.adoc @@ -18,7 +18,7 @@ include::tf2-dev-24-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -37,7 +37,7 @@ include::tf2-dev-24-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_24_sequence, target=puml-dev-24-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-24-sequence.puml[] @@ -54,7 +54,7 @@ include::../../plantuml/vol2-figure-dev-24-sequence.puml[] The corresponding message to seek <> based on filter criteria is called _{var_label_dev_24_message_probe}_. Note that the {var_label_dev_24_message_probe} message described in this clause is a generic/abstract concept that can be implemented differently. -It should not be confused with actual transport message specifications like, e.g. the WS-Discovery Probe message as described in <>. +It should not be confused with actual transport message specifications like, e.g., the WS-Discovery Probe message as described in <>. If a specific <> is unknown to a <>, the <> can send a {var_label_dev_24_message_probe} multicast message to all listening <>s. Limited but sufficient information is provided with the message to enable <>s to determine if they match the <> requested by the <>. @@ -82,7 +82,7 @@ When a <> sends this message, every recei The {var_label_dev_24_message_probe_match} message is sent as part of the BICEPS _explicit discovery_ protocol in response to an incoming <> message. Note that the {var_label_dev_24_message_probe_match} message described in this clause is a generic/abstract concept that can be implemented differently. -It should not be confused with actual transport message specifications like, e.g. the WS-Discovery ProbeMatch message as described in <>. +It should not be confused with actual transport message specifications like, e.g., the WS-Discovery ProbeMatch message as described in <>. The {var_label_dev_24_message_probe_match} message is a uni-cast message that is sent by a <> when an incoming <> message contains a <> that matches the <>'s <>. Limited but sufficient information is provided with the message to enable <>s to determine a matching <>'s <> and <>. @@ -113,7 +113,7 @@ The <> that receives a {var_label_dev_24_ The corresponding message to seek <>s based on a unique identifier is called _{var_label_dev_24_message_resolve}_. Note that the {var_label_dev_24_message_resolve} message described in this clause is a generic/abstract concept that can be implemented differently. -It should not be confused with actual transport message specifications like, e.g. the WS-Discovery Resolve message as described in <>. +It should not be confused with actual transport message specifications like, e.g., the WS-Discovery Resolve message as described in <>. If a specific <> is known to a <>, the <> can send a {var_label_dev_24_message_resolve} multicast message to all listening <>s. Limited but sufficient information is provided with the message to enable <>s to determine if they match the <> requested by the <>. @@ -145,7 +145,7 @@ When a <> sends this message, every recei The {var_label_dev_24_message_resolve_match} message is sent as part of the BICEPS _explicit discovery_ protocol in response to an incoming <> message. Note that the {var_label_dev_24_message_resolve_match} message described in this clause is a generic/abstract concept that can be implemented differently. -It should not be confused with actual transport message specifications like, e.g. the WS-Discovery ResolveMatch message as described in <>. +It should not be confused with actual transport message specifications like, e.g., the WS-Discovery ResolveMatch message as described in <>. The {var_label_dev_24_message_resolve_match} message is a uni-cast message that is sent by a <> when an incoming <> message contains a <> that matches the <>'s <>. Limited but sufficient information is provided with the message to enable <>s to determine a matching <>'s <>. diff --git a/asciidoc/volume2/dev-25/tf2-dev-25.adoc b/asciidoc/volume2/dev-25/tf2-dev-25.adoc index eb37646..d3da493 100644 --- a/asciidoc/volume2/dev-25/tf2-dev-25.adoc +++ b/asciidoc/volume2/dev-25/tf2-dev-25.adoc @@ -9,7 +9,7 @@ include::tf2-dev-25-summary.adoc[] ==== Actor Roles -.Actor Roles DEV-25 +.Actor Roles [DEV-25] [cols="1,2"] |=== |Actor |Roles @@ -28,7 +28,7 @@ include::tf2-dev-25-summary.adoc[] * <> Section 7.3 Service Model ==== Messages -.Message Interaction Diagram DEV-25 +.Message Interaction Diagram [DEV-25] [plantuml#vol2_figure_dev_25_sequence, target=puml-dev-25-sequence, format=svg, 40width=100%] .... @@ -64,12 +64,12 @@ The GetMetadataResponse message is sent whenever a <> characteristics that typically vary from one <> to another of the same kind, e.g.: +Device Metadata:: Expresses <> characteristics that typically vary from one <> to another of the same kind, for example: * Friendly name * Firmware version * Serial number [#message_semantics_discover_biceps_services_model] -Model Metadata:: Expresses <> characteristics that are typically fixed across all <>s of the same model by their <>, e.g.: +Model Metadata:: Expresses <> characteristics that are typically fixed across all <>s of the same model by their <>, for example: * <> * Model name * Model number diff --git a/asciidoc/volume2/dev-27/tf2-dev-27.adoc b/asciidoc/volume2/dev-27/tf2-dev-27.adoc index f0190a5..f848725 100644 --- a/asciidoc/volume2/dev-27/tf2-dev-27.adoc +++ b/asciidoc/volume2/dev-27/tf2-dev-27.adoc @@ -20,7 +20,7 @@ include::tf2-dev-27-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -47,7 +47,7 @@ When at some point the subscription has to be ended, the <> message. Specialized notification messages are detailed in <> and <>, based on payload content and trigger events. +CAUTION: Transaction [{var_transaction_id}] supports a general <> message. Specialized notification messages are detailed in <> and <>, based on payload content and trigger events. [#vol2_clause_dev_27_message_subscribe] ===== {var_label_dev_27_message_subscribe} Message @@ -109,7 +109,7 @@ The {var_label_dev_27_message_subscribe_response} message is sent whenever a <> to renew or cancel the subscription. +[[payload_dev_27_subscribe_response_subscription_manager]]Subscription Manager:: Dedicated instance that manages the subscription, i.e., allows for a <> to renew or cancel the subscription. [[payload_dev_27_subscribe_response_expiration_time]]Expiration Time:: Actual expiration time, which does not necessarily equal the requested expiration time. [#vol2_clause_dev_27_message_probe_match_expected_actions] @@ -162,7 +162,7 @@ The {var_label_dev_27_message_renew} message is sent whenever a subscription is [#vol2_clause_dev_27_message_renew_message_semantics] ====== Message Semantics -[[payload_dev_27_subscribe_response_subscription_manager]]Subscription Manager:: Dedicated instance that manages the subscription, i.e. allows for a <> to renew or cancel the subscription. +[[payload_dev_27_subscribe_response_subscription_manager]]Subscription Manager:: Dedicated instance that manages the subscription, i.e., allows for a <> to renew or cancel the subscription. [[payload_dev_27_renew_expiration_time]]Expiration Time:: A new time requested for subscription expiration. [#vol2_clause_dev_27_message_renew_expected_actions] @@ -249,7 +249,7 @@ Once received, the <> cannot expect any f [#vol2_clause_dev_27_message_subscription_end] ===== {var_label_dev_27_message_subscription_end} Message -The {var_label_dev_27_message_subscription_end} is delivered by a <> to signify the expected or unexpected end of a subscription, e.g. due to a shutdown of the <>. +The {var_label_dev_27_message_subscription_end} is delivered by a <> to signify the expected or unexpected end of a subscription, e.g., due to a shutdown of the <>. [#vol2_clause_dev_27_message_subscription_end_trigger_events] ====== Trigger Events diff --git a/asciidoc/volume2/dev-28/tf2-dev-28.adoc b/asciidoc/volume2/dev-28/tf2-dev-28.adoc index 70f77c0..22922f8 100644 --- a/asciidoc/volume2/dev-28/tf2-dev-28.adoc +++ b/asciidoc/volume2/dev-28/tf2-dev-28.adoc @@ -14,7 +14,7 @@ include::tf2-dev-28-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -33,7 +33,7 @@ include::tf2-dev-28-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_28_sequence, target=puml-dev-28-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-28-sequence.puml[] @@ -42,7 +42,7 @@ include::../../plantuml/vol2-figure-dev-28-sequence.puml[] // ---------- EpisodicContextReport --------- -CAUTION: Transaction {var_transaction_id} supports a specialized instance of the general <> message, based on payload content and trigger events. +CAUTION: Transaction [{var_transaction_id}] supports a specialized instance of the general <> message, based on payload content and trigger events. [#vol2_clause_dev_28_message_notification] ===== {var_label_dev_28_message_contextreport} Message diff --git a/asciidoc/volume2/dev-29/tf2-dev-29.adoc b/asciidoc/volume2/dev-29/tf2-dev-29.adoc index d183a53..cf1dafc 100644 --- a/asciidoc/volume2/dev-29/tf2-dev-29.adoc +++ b/asciidoc/volume2/dev-29/tf2-dev-29.adoc @@ -14,7 +14,7 @@ include::tf2-dev-29-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -33,7 +33,7 @@ include::tf2-dev-29-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_29_sequence, target=puml-dev-29-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-29-sequence.puml[] @@ -42,7 +42,7 @@ include::../../plantuml/vol2-figure-dev-29-sequence.puml[] // ---------- Notification --------- -CAUTION: Transaction {var_transaction_id} supports a specialized instance of the general <> message, based on payload content and trigger events. +CAUTION: Transaction [{var_transaction_id}] supports a specialized instance of the general <> message, based on payload content and trigger events. [#vol2_clause_dev_29_message_notification] ===== {var_label_dev_29_message_notification} Message diff --git a/asciidoc/volume2/dev-30/tf2-dev-30.adoc b/asciidoc/volume2/dev-30/tf2-dev-30.adoc index d2befbe..978c783 100644 --- a/asciidoc/volume2/dev-30/tf2-dev-30.adoc +++ b/asciidoc/volume2/dev-30/tf2-dev-30.adoc @@ -14,7 +14,7 @@ include::tf2-dev-30-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -33,7 +33,7 @@ include::tf2-dev-30-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_30_sequence, target=puml-dev-30-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-30-sequence.puml[] diff --git a/asciidoc/volume2/dev-34/tf2-dev-34.adoc b/asciidoc/volume2/dev-34/tf2-dev-34.adoc index 6796c4e..addd9a5 100644 --- a/asciidoc/volume2/dev-34/tf2-dev-34.adoc +++ b/asciidoc/volume2/dev-34/tf2-dev-34.adoc @@ -13,7 +13,7 @@ include::tf2-dev-34-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -32,7 +32,7 @@ include::tf2-dev-34-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_34_sequence, target=puml-dev-34-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-34-sequence.puml[] diff --git a/asciidoc/volume2/dev-35/tf2-dev-35.adoc b/asciidoc/volume2/dev-35/tf2-dev-35.adoc index 895811b..c25886f 100644 --- a/asciidoc/volume2/dev-35/tf2-dev-35.adoc +++ b/asciidoc/volume2/dev-35/tf2-dev-35.adoc @@ -13,7 +13,7 @@ include::tf2-dev-35-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -34,14 +34,14 @@ include::tf2-dev-35-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_35_sequence, target=puml-dev-35-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-35-sequence.puml[] .... :var_duplicated_transaction: {var_transaction_id} -:var_dupicates_list: DEV-27 (<>) and DEV-38 (<>) +:var_dupicates_list: [DEV-27] (<>) and [DEV-38] (<>) include::../dev-duplicate-disclaimer.adoc[] [#vol2_clause_dev_35_establish_medical_data_exchange_ses] diff --git a/asciidoc/volume2/dev-36/tf2-dev-36.adoc b/asciidoc/volume2/dev-36/tf2-dev-36.adoc index 88b193b..15c9b79 100644 --- a/asciidoc/volume2/dev-36/tf2-dev-36.adoc +++ b/asciidoc/volume2/dev-36/tf2-dev-36.adoc @@ -11,7 +11,7 @@ include::tf2-dev-36-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -30,14 +30,14 @@ include::tf2-dev-36-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_36_sequence, target=puml-dev-36-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-36-sequence.puml[] .... :var_duplicated_transaction: {var_transaction_id} -:var_dupicates_list: DEV-29 (<>) and DEV-39 (<>) +:var_dupicates_list: [DEV-29] (<>) and [DEV-39] (<>) include::../dev-duplicate-disclaimer.adoc[] [#vol2_clause_dev_36_publish_medical_data_ses] diff --git a/asciidoc/volume2/dev-37/tf2-dev-37.adoc b/asciidoc/volume2/dev-37/tf2-dev-37.adoc index 51b313b..cefb096 100644 --- a/asciidoc/volume2/dev-37/tf2-dev-37.adoc +++ b/asciidoc/volume2/dev-37/tf2-dev-37.adoc @@ -12,7 +12,7 @@ include::tf2-dev-37-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -31,7 +31,7 @@ include::tf2-dev-37-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_37_sequence, target=puml-dev-37-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-37-sequence.puml[] @@ -41,7 +41,7 @@ Note that there is no particular get operation for retrieving medical alert stat Thus, the generic GetMdib/GetMdibResponse mechanisms are described here. :var_duplicated_transaction: {var_transaction_id} -:var_dupicates_list: DEV-30 (<>) +:var_dupicates_list: [DEV-30] (<>) include::../dev-duplicate-disclaimer.adoc[] [#vol2_clause_dev_37_retrieve_medical_data_ses] diff --git a/asciidoc/volume2/dev-38/tf2-dev-38.adoc b/asciidoc/volume2/dev-38/tf2-dev-38.adoc index 88997a5..f932a28 100644 --- a/asciidoc/volume2/dev-38/tf2-dev-38.adoc +++ b/asciidoc/volume2/dev-38/tf2-dev-38.adoc @@ -12,7 +12,7 @@ include::tf2-dev-38-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -33,14 +33,14 @@ include::tf2-dev-38-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_38_sequence, target=puml-dev-38-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-38-sequence.puml[] .... :var_duplicated_transaction: {var_transaction_id} -:var_dupicates_list: DEV-27 (<>) and DEV-35 (<>) +:var_dupicates_list: [DEV-27] (<>) and [DEV-35] (<>) include::../dev-duplicate-disclaimer.adoc[] [#vol2_clause_dev_38_establish_medical_alert_exchange_ses] diff --git a/asciidoc/volume2/dev-39/tf2-dev-39.adoc b/asciidoc/volume2/dev-39/tf2-dev-39.adoc index 2378756..44228cc 100644 --- a/asciidoc/volume2/dev-39/tf2-dev-39.adoc +++ b/asciidoc/volume2/dev-39/tf2-dev-39.adoc @@ -11,7 +11,7 @@ include::tf2-dev-39-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -30,7 +30,7 @@ include::tf2-dev-39-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_39_sequence, target=puml-dev-39-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-39-sequence.puml[] diff --git a/asciidoc/volume2/dev-40/tf2-dev-40.adoc b/asciidoc/volume2/dev-40/tf2-dev-40.adoc index 1aa14ef..ee33213 100644 --- a/asciidoc/volume2/dev-40/tf2-dev-40.adoc +++ b/asciidoc/volume2/dev-40/tf2-dev-40.adoc @@ -13,7 +13,7 @@ include::tf2-dev-40-summary.adoc[] ==== Actor Roles -.Actor Roles {var_transaction_id} +.Actor Roles [{var_transaction_id}] [cols="1,2"] |=== |Actor |Roles @@ -32,7 +32,7 @@ include::tf2-dev-40-summary.adoc[] ==== Messages -.Message Interaction Diagram {var_transaction_id} +.Message Interaction Diagram [{var_transaction_id}] [plantuml#vol2_figure_dev_40_sequence, target=puml-dev-40-sequence, format=svg, 40width=100%] .... include::../../plantuml/vol2-figure-dev-40-sequence.puml[] @@ -42,7 +42,7 @@ Note that there is no particular get operation for retrieving medical alert stat Thus, the generic GetMdib/GetMdibResponse mechanisms are described here. :var_duplicated_transaction: {var_transaction_id} -:var_dupicates_list: DEV-30 (<>) and DEV-37 (<>) +:var_dupicates_list: [DEV-30] (<>) and [DEV-37] (<>) include::../dev-duplicate-disclaimer.adoc[] [#vol2_clause_dev_40_retrieve_medical_alert_status_ses] diff --git a/asciidoc/volume2/dev-duplicate-disclaimer.adoc b/asciidoc/volume2/dev-duplicate-disclaimer.adoc index 847d249..b87f8b0 100644 --- a/asciidoc/volume2/dev-duplicate-disclaimer.adoc +++ b/asciidoc/volume2/dev-duplicate-disclaimer.adoc @@ -1,4 +1,4 @@ -CAUTION: Transaction {var_duplicated_transaction} syntactically duplicates {var_dupicates_list}. This a deliberate action as {var_transaction_id} is expected to receive <> constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. +CAUTION: Transaction [{var_duplicated_transaction}] syntactically duplicates {var_dupicates_list}. This a deliberate action as [{var_transaction_id}] is expected to receive <> constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. :!var_duplicated_transaction: :!var_dupicates_list: \ No newline at end of file diff --git a/asciidoc/volume2/dev-x-default-ses-secured-mode.adoc b/asciidoc/volume2/dev-x-default-ses-secured-mode.adoc index 6c78c03..6ec880a 100644 --- a/asciidoc/volume2/dev-x-default-ses-secured-mode.adoc +++ b/asciidoc/volume2/dev-x-default-ses-secured-mode.adoc @@ -6,10 +6,10 @@ Requirements from the <>, <>, and re For additional guidance, see <>. ===== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ===== Effectiveness Requirements & Considerations -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ===== Security Requirements & Considerations This transaction is intended to execute over *_SECURED_* transmission channels. diff --git a/asciidoc/volume2/dev-x-default-ses-unsecured-mode.adoc b/asciidoc/volume2/dev-x-default-ses-unsecured-mode.adoc index 3fa66d0..608333a 100644 --- a/asciidoc/volume2/dev-x-default-ses-unsecured-mode.adoc +++ b/asciidoc/volume2/dev-x-default-ses-unsecured-mode.adoc @@ -6,10 +6,10 @@ Requirements from the <>, <>, and re For additional guidance, see <>. ===== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ===== Effectiveness Requirements & Considerations -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ===== Security Requirements & Considerations This transaction is intended to execute over *_UNSECURED_* transmission channels. diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc index d0c1081..4f3b2f2 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc @@ -2,11 +2,11 @@ === SDPi ACM Gateway -- Mapping ==== Scope -This chapter defines the mapping from the <> content as defined in this document and its underlying standards, to IHE Alert Communication Management (ACM) profile messages as defined in the <>. +This chapter defines the mapping from the <> content as defined in this document and its underlying standards, to IHE Alert Communication Management (ACM) Profile messages as defined in the <>. The <> represents the Alarm Reporter (AR) role of the IHE ACM profile. -The following sections supplement the IHE ACM profile as appropriate. If there are no supplementing definitions, the definitions as described in the <> apply. +The following sections supplement the IHE ACM Profile as appropriate. If there are no supplementing definitions, the definitions as described in the <> apply. ==== Referenced Standards & Profiles This section provides an overview about the referenced standards and profiles used in this chapter: @@ -18,19 +18,19 @@ This section provides an overview about the referenced standards and profiles us * <> ==== Private MDC Codes Consideration -Please refer to general section <>. +Please refer to general Section <>. ==== HL7 Segment Descriptions The following sections refer to the *Appendix B Common Segment Descriptions* of the <>. ===== MSH - Message Header Segment -Please refer to general section <>. +Please refer to general Section <>. ===== PID - Patient Identification Segment -Please refer to general section <>. +Please refer to general Section <>. ===== PV1 - Patient Visit Segment -Please refer to general section <>. +Please refer to general Section <>. ===== OBR - Observation Request Segment The HL7 Observation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields. @@ -73,7 +73,6 @@ For the *initial alert event announcement message*, a < [%collapsible] ==== NOTE: This identifer consists of the *pm:AlertConditionState/@DescriptorHandle* plus the *SequenceId* plus the *pm:AlertConditionState/@StateVersion* of the state report. - ==== .Examples @@ -100,7 +99,6 @@ For the *subsequent alert event messages for the same alert event*, a <>. +Please refer to general Section <>. [#ref_acm_equipment_id_mapping] ===== Equipment Instance Identifier Mapping -Please refer to general section <>. +Please refer to general Section <>. [#ref_acm_obx_device_related_mapping] ====== Device-related OBX Segments @@ -246,14 +244,13 @@ A <> shall export device-related OBX segments, which de [%collapsible] ==== NOTE: There might be up to three device-related OBX segments for the MDS, VMD, and CHANNEL dependent on the specific device's containment tree. The general mapping of the device-related OBX segments is defined in table <>. - ==== **** .R8058 [sdpi_requirement#r8058,sdpi_req_level=shall] **** -If a private *<>* code is used for the coding of the SDC device-related element, the identifier shall be mapped as described in section <>. +If a private *<>* code is used for the coding of the SDC device-related element, the identifier shall be mapped as described in Section <>. **** [#ref_tbl_acm_obx_device_related_mapping] @@ -303,7 +300,7 @@ Note that this field is only required to be set for the MDS and/or the VMD eleme [#ref_acm_obs_id_mapping,sdpi_level=+1] ====== Observation Identifier Mapping -Please refer to general section <>. +Please refer to general Section <>. [NOTE] ==== @@ -333,7 +330,6 @@ A <> shall export an Event Identification OBX segment w [%collapsible] ==== NOTE: The mapping differs for physiological alert events and technical/advisory alert events (please refer also to <> for further information). - ==== **** @@ -360,7 +356,6 @@ NOTE: This either applies to a change of the *pm:AlertConditionState* or the *pm NOTE: The date/time to be set in the OBX-14 field relates to the alert event phase. <> defines the date/time mapping per alert event phase. NOTE: The HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (please refer to <> for further information). - ==== **** @@ -383,21 +378,21 @@ NOTE: The HL7 date & time format differs from the xsd date/time formats and requ |update |*pm:AlertConditionState++++++/pm:DeterminationTime* or *pm:AlertSignalState++++++/pm:DeterminationTime* for any updates/changes to be reported but does not match any other Alert Event Phase mapping criteria. -Note that the *pm:AlertConditionState++++++/pm:DeterminationTime* changes only when the *@Presence* attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g. alert priority). +Note that the *pm:AlertConditionState++++++/pm:DeterminationTime* changes only when the *@Presence* attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g., alert priority). |escalate |*pm:AlertConditionState++++++/pm:DeterminationTime* which represents the change of the alert priority. Please refer to <>. -Note that the *pm:AlertConditionState++++++/pm:DeterminationTime* changes only when the *@Presence* attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g. alert priority). +Note that the *pm:AlertConditionState++++++/pm:DeterminationTime* changes only when the *@Presence* attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g., alert priority). |deescalate |*pm:AlertConditionState++++++/pm:DeterminationTime* which represents the change of the alert priority. Please refer to <>. -Note that the *pm:AlertConditionState++++++/pm:DeterminationTime* changes only when the *@Presence* attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g. alert priority). +Note that the *pm:AlertConditionState++++++/pm:DeterminationTime* changes only when the *@Presence* attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g., alert priority). |reset |*pm:AlertSignalState++++++/pm:DeterminationTime* which represents the end of a latched alert event state. @@ -412,7 +407,7 @@ The event identification mapping for a physiological alert is defined in table < .R8063 [sdpi_requirement#r8063,sdpi_req_level=shall] **** -If a private *<>* code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in section <>. +If a private *<>* code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in Section <>. **** [#ref_tbl_acm_obx_event_phy_mapping] @@ -497,7 +492,7 @@ The event identification mapping for a technical alert is defined in table <>* code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in section <>. +If a private *<>* code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in Section <>. **** [#ref_tbl_acm_obx_event_tec_mapping] @@ -664,7 +659,7 @@ The source identification mapping for a technical alert is defined in table <>* code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in section <>. +If a private *<>* code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in Section <>. **** [#ref_tbl_acm_obx_source_tec_mapping] @@ -849,12 +844,12 @@ Note that for latching alert signals, the Alert State (see also <>) changed to a higher priority; e.g. from *"PM"* to *"PH"*. +|Alert Priority (see also <>) changed to a higher priority; e.g., from *"PM"* to *"PH"*. Please refer to <>. |deescalate -|Alert Priority (see also <>) changed to a lower priority; e.g. from *"PH"* to *"PM"*. +|Alert Priority (see also <>) changed to a lower priority; e.g., from *"PH"* to *"PM"*. Please refer to <>. @@ -1072,7 +1067,6 @@ A <> shall map the SDC *pm:AlertConditionDescriptor/@Pr [%collapsible] ==== NOTE: The mapping is defined in table <>. - ==== .Examples diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc index 53aa9f5..7c8c17c 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc @@ -2,11 +2,11 @@ === SDPi DEC Gateway -- Mapping ==== Scope -This chapter defines the mapping from the <> content as defined in this document and its underlying standards, to IHE Device Enterprise Communication (DEC) profile messages as defined in the <>. +This chapter defines the mapping from the <> content as defined in this document and its underlying standards, to IHE Device Enterprise Communication (DEC) Profile messages as defined in the <>. The <> represents the Device Observation Reporter (DOR) role of the IHE DEC profile. -The following sections supplement the IHE DEC profile as appropriate. If there are no supplementing definitions, the definitions as described in the <> will apply. +The following sections supplement the IHE DEC Profile as appropriate. If there are no supplementing definitions, the definitions as described in the <> will apply. ==== Referenced Standards & Profiles This section provides an overview about the referenced standards and profiles used in this chapter: @@ -17,16 +17,16 @@ This section provides an overview about the referenced standards and profiles us * <> ==== Private MDC Codes Consideration -Please refer to general section <>. +Please refer to general Section <>. ==== HL7 Segment Descriptions The following sections refer to the *Appendix B Common Segment Descriptions* of the <>. ===== MSH - Message Header Segment -Please refer to general section <>. +Please refer to general Section <>. ===== PID - Patient Identification Segment -Please refer to general section <>. +Please refer to general Section <>. ===== Height and Weight Mapping @@ -237,7 +237,7 @@ When there are further updates of the weight value after the association of the |=== ===== PV1 - Patient Visit Segment -Please refer to general section <>. +Please refer to general Section <>. ===== OBR - Observation Request Segment The HL7 Obervation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields. @@ -319,8 +319,7 @@ A <> shall export continuously (periodically) measured .Notes [%collapsible] ==== -NOTE: It is up to the <> how the export interval is defined. The interval might be a fixed interval of e.g. 30 seconds, or a configurable interval ranging e.g. between 10 seconds and 2 minutes. - +NOTE: It is up to the <> how the export interval is defined. The interval might be a fixed interval of e.g., 30 seconds, or a configurable interval ranging e.g., between 10 seconds and 2 minutes. ==== **** @@ -333,8 +332,7 @@ A <> shall set the OBR-7 field to the start date and ti .Notes [%collapsible] ==== -NOTE: If, for example, the export interval is set to 30 seconds, the <> will export HL7 messages every 30 seconds with the OBR-7 field set to start date and time of the interval e.g. *20231030155930*, *20231030160000*, *20231030160030*, and so on. - +NOTE: If, for example, the export interval is set to 30 seconds, the <> will export HL7 messages every 30 seconds with the OBR-7 field set to start date and time of the interval e.g., *20231030155930*, *20231030160000*, *20231030160030*, and so on. ==== **** @@ -348,7 +346,6 @@ A <> shall export the latest metric value of all contin [%collapsible] ==== NOTE: The OBR-7 field is set to the start time of the interval. The individual periodic metric value *@DeterminationTime* is basically ignored, but has to be within the time boundaries of the current export interval. - ==== **** @@ -364,7 +361,6 @@ For exporting episodic metric values and the absence of any continuously measure NOTE: Episodic metric values are usually exported along with the periodic metric values in the same export intervals. However, if a device does not provide periodic metric values in the current export interval, episodic metric values are exported in current export interval without periodic metric values. NOTE: The *pm:AbstractMetricState++++++/pm:MetricValue++++++/@DeterminationTime* of an episodic metric value is set in the OBX-14 field and will override the timestamp defined in the OBR-7 field. - ==== **** @@ -385,7 +381,7 @@ A <> may set the OBR-8 field to the end date and time o ==== NOTE: This requirement relates to the OBR-7 field mapping. Please refer to <> for further information. -NOTE: If, for example, the export interval is set to 30 seconds, the <> will export HL7 messages every 30 seconds with the OBR-7 field set to start date and time of the current interval and the OBR-8 field set to the start date and time of the next interval e.g. *20231030155930*|*20231030160000*, *20231030160000*|*20231030160030*, and so on. +NOTE: If, for example, the export interval is set to 30 seconds, the <> will export HL7 messages every 30 seconds with the OBR-7 field set to start date and time of the current interval and the OBR-8 field set to the start date and time of the next interval e.g., *20231030155930*|*20231030160000*, *20231030160000*|*20231030160030*, and so on. ==== **** @@ -443,7 +439,7 @@ NOTE: The SDC operator context is only valid when the *pm:OperatorContextState/@ | |OBR-10/XCN-6 -|Prefix (e.g. DR) +|Prefix (e.g., DR) |pm:OperatorContextState /pm:OperatorDetails /pm:Title @@ -511,11 +507,11 @@ A <> shall leave the OBX-2 field empty for OBX segments |=== ====== OBX-3 Observation Identifier -Please refer to general section <>. +Please refer to general Section <>. [#ref_dec_obx4] ====== OBX-4 Observation Sub-ID -Please refer to general section <>. +Please refer to general Section <>. ====== OBX-5 Observation Value @@ -612,7 +608,7 @@ the OBX-2 is required to be set to *"ST"* (see also <> .R8022 [sdpi_requirement#r8022,sdpi_req_level=shall] **** -If a private *<>* code is used for the coding of the SDC coded element value in OBX-5 mapping, a <> shall map the identifier as described in section <>. +If a private *<>* code is used for the coding of the SDC coded element value in OBX-5 mapping, a <> shall map the identifier as described in Section <>. **** [#ref_tbl_dec_obx5_enum_mapping] @@ -666,7 +662,7 @@ NOTE: For a device-releted element such as MDS, VMD, CHANNEL, or other metric ty .R8024 [sdpi_requirement#r8024,sdpi_req_level=shall] **** -If a private *<>* code is used for the coding of the SDC measurement unit of a metric, a <> shall map the identifier as described in section <>. +If a private *<>* code is used for the coding of the SDC measurement unit of a metric, a <> shall map the identifier as described in Section <>. **** [#ref_tbl_dec_obx6_mapping] @@ -726,7 +722,7 @@ A <> shall not set this field to the device measurement .Notes [%collapsible] ==== -NOTE: As stated in <> the reference range can only be set for device related segments (e.g. Channel). Within SDC the device measurement range refers to each metric and cannot be populated on higher levels in the containment tree. +NOTE: As stated in <> the reference range can only be set for device related segments (e.g., Channel). Within SDC the device measurement range refers to each metric and cannot be populated on higher levels in the containment tree. ==== **** @@ -868,7 +864,7 @@ Or set to "AMEAS\^auto-measurement^MDC" if required. |=== ====== OBX-18 Equipment Instance Identifier -Please refer to general section <>. +Please refer to general Section <>. ====== OBX-20 Observation Site @@ -893,7 +889,7 @@ NOTE: For a device-releted element such as MDS, VMD, or CHANNEL, the OBX-20 fiel .R8035 [sdpi_requirement#r8035,sdpi_req_level=shall] **** -If a private *<>* code is used for the coding of a body site, a <> shall map the identifier as described in section <>. +If a private *<>* code is used for the coding of a body site, a <> shall map the identifier as described in Section <>. **** [#ref_tbl_dec_obx20_mapping] diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc index 0181c6d..45beb5f 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc @@ -16,7 +16,7 @@ NOTE: <>, <>, <>* code is used for the coding of the SDC containment tree element, the <> / <> shall map an identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric as described in section <>. +If a private *<>* code is used for the coding of the SDC containment tree element, the <> / <> shall map an identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric as described in Section <>. **** [#ref_tbl_dec_obx3_mds_mapping] diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc index e9695d9..ebb5a39 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc @@ -21,7 +21,7 @@ A <> / <> shall assign the han .Notes [%collapsible] ==== -NOTE: This implies that, e.g. channel elements may use the same numbers as VMD elements but on the channel level the numbers must be unique for the channels related to the same VMD. +NOTE: This implies that, e.g., channel elements may use the same numbers as VMD elements but on the channel level the numbers must be unique for the channels related to the same VMD. NOTE: There is no requirement to preserve the same assigned number for a containment tree element from message to message, but it is highly recommended since this makes it much easier for the DOC to process the HL7 V2 messages. ==== diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc index 4405379..0e13057 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc @@ -26,7 +26,7 @@ If <> is met, then a <> / <> defines the mapping of the <> patient identification to the data fields of the HL7 data type *CX* used in the PID-3 field. @@ -128,7 +128,7 @@ NOTE: <> defines the mapping of the SDC patient name infor | |PID-5/XPN-5 -|Prefix (e.g. DR) +|Prefix (e.g., DR) |pm:PatientContextState++++++/pm:CoreData++++++/pm:Title | @@ -210,7 +210,7 @@ xsd:date: *2001-10-26* -> HL7 DTM: *20011026* [%autowidth] [cols="1"] |=== -a| *SDPi Supplement Version Note*: At the moment, there are various opinions on how to map the biological sex vs. the administrative sex (gender) to an IHE PCD profile conform HL7 V2 message. +a| *SDPi Supplement Version Note*: At the moment, there are various opinions on how to map the biological sex vs. the administrative sex (gender) to an IHE DEV/PCD profile conform HL7 V2 message. The SDC BICEPS standard defines a generic field for the patient's sex (*pm:PatientContextState/pm:CoreData/pm:Sex*). This field shall be set to the biological sex (or sex for clinical use). @@ -220,7 +220,7 @@ The HL7 V2.6 messaging standard only supports a "Administrative Sex" field in th [none] . *STANDARDIZATION NOTE:* There is active work to finalize the informatics standards related to sex and gender, including within HL7, SNOMED, ISO/TC215 and in other standards development organizations. -Once this standardization is complete, especially within HL7 FHIR and Version 2, the SDC standards and the SDPi profiles and gateway specifications will be harmonized. +Once this standardization is complete, especially within HL7 FHIR and Version 2, the SDC standards and the SDPi Profiles and gateway specifications will be harmonized. Until that time, the mappings below represent a "best effort" given the status of the underlying standards. See related note in <>. @@ -229,9 +229,9 @@ The following list a couple of options and any comments from the reviewers are h . *No mapping of sex/gender information at all*: the information of the patient's sex and gender shall not be mapped at all. Pros: no risk of mapping incorrect information. Cons: no information about the sex set at the device which may have influenced certain clinical calculations and algorithms. -. *Map the "sex for clinical use" to the PID-8 Administrative Sex field*: in the context of a PoC device the sex for clinical use is the most important information for clinical calculations and algorithm. Therefore, this information shall be mapped to the PID-8 Administrative Sex field - even this is not necessarily the administrative gender. In addition, the Administrative Sex/Gender may be mapped to a separate OBX segment (only possible for DEC profile). Pros: this is backward compatible to the existing IHE PCD profiles. Cons: the information are not set in the correct field and may lead to wrong interpretations. +. *Map the "sex for clinical use" to the PID-8 Administrative Sex field*: in the context of a PoC device the sex for clinical use is the most important information for clinical calculations and algorithm. Therefore, this information shall be mapped to the PID-8 Administrative Sex field - even this is not necessarily the administrative gender. In addition, the Administrative Sex/Gender may be mapped to a separate OBX segment (only possible for DEC profile). Pros: this is backward compatible to the existing IHE PCD Profiles. Cons: the information are not set in the correct field and may lead to wrong interpretations. -. *Map the "sex for clinical use" in a separate OBX segment (only possible for DEC profile but not for ACM) and the Administrative Sex/Gender to the PID-8 Administrative Sex field*: the administrative sex/gender information is mapped to the correctly named PID-8 "Administrative Sex" field, and the sex for clinical use is provided in a separate OBX segment in the IHE DEC profile conform export. The sex for clinical use information will be not available in the ACM profile conform export. Pros: the information are mapped to the correct fields. Cons: this mapping might not be backward compatible to the existing IHE PCD profile actors (reporter/consumer). Information of the sex for clinical use may get lost in some profiles such as ACM. +. *Map the "sex for clinical use" in a separate OBX segment (only possible for the DEC Profile but not for ACM) and the Administrative Sex/Gender to the PID-8 Administrative Sex field*: the administrative sex/gender information is mapped to the correctly named PID-8 "Administrative Sex" field, and the sex for clinical use is provided in a separate OBX segment in the IHE DEC Profile conform export. The sex for clinical use information will be not available in the ACM Profile conform export. Pros: the information are mapped to the correct fields. Cons: this mapping might not be backward compatible to the existing IHE DEV/PCD profile actors (reporter/consumer). Information of the sex for clinical use may get lost in some profiles such as ACM. *REVIEWER QUESTION*: Please review the options listed above and provide comments on the mapping of this semantic content. diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc index f4c84d7..e6c9e4a 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc @@ -148,7 +148,7 @@ Valid *"Identifier Type Code"* values for a visit number are, for example, *"VN" **** If <> is met, then a <> / <> shall set the PV1-44 field to the patient's admission date/time. -The SDC data model does not support the concept of an admission date/time. There are also different types of admissions; e.g. hospital admission, care unit admission, etc. +The SDC data model does not support the concept of an admission date/time. There are also different types of admissions; e.g., hospital admission, care unit admission, etc. This said, it is up to the <> / <> to figure out the admission date/time to be set in the PV1-44 field. If the gateway is not able to determine the admission date/time, the field is left empty. **** diff --git a/asciidoc/volume2/mdpws-compression/tf2-ch-a-mdpws-compression.adoc b/asciidoc/volume2/mdpws-compression/tf2-ch-a-mdpws-compression.adoc index 41f439c..fbd298a 100644 --- a/asciidoc/volume2/mdpws-compression/tf2-ch-a-mdpws-compression.adoc +++ b/asciidoc/volume2/mdpws-compression/tf2-ch-a-mdpws-compression.adoc @@ -35,7 +35,7 @@ Content-Type: text/xml; charset=UTF-8 Content-Encoding: gzip ---- -The HTTP server decided to encode the response with the gzip compression. Note that servers are not required to actually compress (e.g. due to load conditions or unknown algorithms they are entitled to answer with identity encoding). +The HTTP server decided to encode the response with the gzip compression. Note that servers are not required to actually compress (e.g., due to load conditions or unknown algorithms they are entitled to answer with identity encoding). ==== **** diff --git a/asciidoc/volume2/pretty-print/tf2-ch-a-mdpws-pretty-print.adoc b/asciidoc/volume2/pretty-print/tf2-ch-a-mdpws-pretty-print.adoc index 2e3222e..587d0ea 100644 --- a/asciidoc/volume2/pretty-print/tf2-ch-a-mdpws-pretty-print.adoc +++ b/asciidoc/volume2/pretty-print/tf2-ch-a-mdpws-pretty-print.adoc @@ -4,7 +4,7 @@ XML processor implementations may pretty-print XML by default when serializing X Pretty-printed XML aligns XML elements in new lines and adds indentation where necessary to beautify serialized data and therewith increase human-readability. However, if the serializer is not XML-Schema-agnostic, it ignores _mixed content_ declarations and hence can change the meaning of elements in instance documents that are supposed to contain _mixed content_. -<> requires XML serializers to be XML Schema agnostic. If, e.g. for technical reasons, a serializer cannot be XML Schema agnostic, it is not allowed to pretty-print XML data as it may generate invalid XML markup. +<> requires XML serializers to be XML Schema agnostic. If, e.g., for technical reasons, a serializer cannot be XML Schema agnostic, it is not allowed to pretty-print XML data as it may generate invalid XML markup. .R0013 [sdpi_requirement#r0013,sdpi_req_level=shall] diff --git a/asciidoc/volume2/service-mapping/tf2-ch-a-mdpws-service-mapping.adoc b/asciidoc/volume2/service-mapping/tf2-ch-a-mdpws-service-mapping.adoc index 5547290..4281b9f 100644 --- a/asciidoc/volume2/service-mapping/tf2-ch-a-mdpws-service-mapping.adoc +++ b/asciidoc/volume2/service-mapping/tf2-ch-a-mdpws-service-mapping.adoc @@ -12,6 +12,7 @@ A <> shall at least provide the port type [%collapsible] ==== NOTE: According to <>, the GET SERVICE is the only mandatory service to be implemented. This specification extends the list of mandatory services to increase interoperability between <>s. + NOTE: All port types of SDC are {uri_sdc_wsdl}[available for download]. NOTE: Other port types are currently out of scope of this specification and may be added in a future revision. diff --git a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.2-applicable-attribute-type-codes.adoc b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.2-applicable-attribute-type-codes.adoc index 9606c13..d0ec744 100644 --- a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.2-applicable-attribute-type-codes.adoc +++ b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.2-applicable-attribute-type-codes.adoc @@ -20,7 +20,7 @@ NOTE: Other attributes may be used for types that are not listed in <::| Context-free Code |MDC_ATTR_ID_SOFT -a|Identifier specific to a hospital (non-manufacturer) that is configured by (service) personnel, e.g. a hospital inventory number. Synonyms used by different manufacturers: +a|Identifier specific to a hospital (non-manufacturer) that is configured by (service) personnel, e.g., a hospital inventory number. Synonyms used by different manufacturers: - Equipment label - Device name diff --git a/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.4-extension-gender.adoc b/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.4-extension-gender.adoc index 523e58a..8db9a37 100644 --- a/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.4-extension-gender.adoc +++ b/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.4-extension-gender.adoc @@ -10,7 +10,7 @@ The following sex & gender harmonization policy will be taken in this and future [none] . *STANDARDIZATION NOTE:* There is active work to finalize the informatics standards related to sex and gender, including within HL7, SNOMED, ISO/TC215 and in other standards development organizations. -Once this standardization is complete, especially within HL7 FHIR and Version 2, the SDC standards and the SDPi profiles and gateway specifications will be harmonized. +Once this standardization is complete, especially within HL7 FHIR and Version 2, the SDC standards and the SDPi Profiles and gateway specifications will be harmonized. Until that time, the mappings below represent a "best effort" given the status of the underlying standards. See the related note on sex and gender in the gateway mappings specified in <>. diff --git a/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc b/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc index 1d417fb..27e7c14 100644 --- a/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc +++ b/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc @@ -154,7 +154,7 @@ In addition to specific device specializations (see <> standards community is evaluating the use of safety class elements in the BICEPS specification (see <>), and the related https://github.com/IHE/DEV.SDPi/issues/11[Github Issue #11 _Topic: SDPi-xC with Mixed Device Safety Classes_]. -The result of that discussion will directly impact the BICEPS SES Considerations section below. +The result of that discussion will directly impact the BICEPS SES Considerations Section below. For this version of the specification, the following wording has been suggested: @@ -167,19 +167,19 @@ For this version of the specification, the following wording has been suggested: ====== SES General Considerations Requirements from the <>, <>, and related standards should be fully applied to this technical framework element. -For additional guidance, see section <>. +For additional guidance, see Section <>. ====== Safety Requirements & Considerations -No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ====== Effectiveness Requirements & Considerations -No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ section above. +No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the _<> General Considerations_ Section above. ====== Security Requirements & Considerations Secure exchange of content between medical devices is a foundational requirement for all system-to-system interactions. Though management of secure connections is generally a technical issue and not one specific to semantic content, close consideration should be made to ensure that information exchanged in potentially unsecured contexts does not pose an unacceptable risk. -Additional security requirements and considerations may be identified in the <> profile, and those specified in the _<> General Considerations_ section above. +Additional security requirements and considerations may be identified in the <> profile, and those specified in the _<> General Considerations_ Section above. // 8.3.2. ===== BICEPS Conventions for device specialization content modules diff --git a/asciidoc/volume3/tf3-ch-8.7.3-physiologic-monitor.adoc b/asciidoc/volume3/tf3-ch-8.7.3-physiologic-monitor.adoc index befdaf9..fb1ac25 100644 --- a/asciidoc/volume3/tf3-ch-8.7.3-physiologic-monitor.adoc +++ b/asciidoc/volume3/tf3-ch-8.7.3-physiologic-monitor.adoc @@ -23,7 +23,7 @@ The following BICEPS containment tree represents a highly-simplified physiologic include::../plantuml/vol3-figure-biceps-content-module-physiomon.puml[] .... -The following XML snippet profiles BICEPS semantics in line with the containment tree shown in <>. The snippet focuses on the descriptive part of the MDIB file and, more specifically, on the VMDs / Channels / Metrics substructure (i.e. the leftmost branch of <>): +The following XML snippet profiles BICEPS semantics in line with the containment tree shown in <>. The snippet focuses on the descriptive part of the MDIB file and, more specifically, on the VMDs / Channels / Metrics substructure (i.e., the leftmost branch of <>): .BICEPS MDIB snippet of physiologic monitor describing VMDs / Channels / Metrics [%collapsible] diff --git a/asciidoc/volume3/tf3-main.adoc b/asciidoc/volume3/tf3-main.adoc index 3f9c3b2..a0cc962 100644 --- a/asciidoc/volume3/tf3-main.adoc +++ b/asciidoc/volume3/tf3-main.adoc @@ -19,14 +19,14 @@ a| *SDPi Supplement Version Note*: The organization of this Volume 3 supplement . Addition of <> content to a volume that is organized according to the "classic" <> domain information model (DIM). -For this version of the supplement, content from the 2019 version that was in sections 3 and 7 has now been collected into a single section 8. +For this version of the supplement, content from the 2019 version that was in sections 3 and 7 has now been collected into a single Section 8. In order to clearly identify the supplement content that is related to <>, specific sections with <> in the title have been added. Although this results in a fairly clean supplement document, the flow of the outline is at times non sequitur. To address that problem -- again arising from the original volume organization never contemplating additional semantic content standards alignment beyond the Classic DIM -- subsections that are aligned with the Classic DIM have been organized in a subsection with that scope. That new content which is based on <> is also contained within a similarly labeled set of subsections -- both at the same outline level. -For the existing TF-3 content in the <>, especially section 3, though this supplement includes editor guidance for which sections are mapped where in the updated outline, the actual content is a mix of general device informatics topics and details that are based on the "classic" <> DIM. +For the existing TF-3 content in the <>, especially Section 3, though this supplement includes editor guidance for which sections are mapped where in the updated outline, the actual content is a mix of general device informatics topics and details that are based on the "classic" <> DIM. *_Updating the existing IHE DEV Technical Framework content will be either deferred to a later version of this SDPi supplement or will be accomplished through a specific Change Proposal (CP) to the published IHE DEV TF-3._* @@ -45,11 +45,11 @@ Subsequent versions of the specification may address this more comprehensively. [%noheader] [cols="1"] |=== -| Move IHE PCD 2019 TF-3 section 3 (text immediately after the section header) to this SDPi 1.1 TF-3 section 8.1 +| Move IHE PCD 2019 TF-3 Section 3 (text immediately after the section header) to this SDPi 1.1 TF-3 Section 8.1 |=== //// -#TODO: Update the IHE PCD 2019 TF-3 section 3 content to be model/format independent# +#TODO: Update the IHE PCD 2019 TF-3 Section 3 content to be model/format independent# //// // 8.2 @@ -58,14 +58,14 @@ Subsequent versions of the specification may address this more comprehensively. [%noheader] [cols="1"] |=== -| Move IHE PCD 2019 TF-3 sections 3.1 to this SDPi 1.1 TF-3 section 8.2 +| Move IHE PCD 2019 TF-3 sections 3.1 to this SDPi 1.1 TF-3 Section 8.2 |=== [%noheader] [%autowidth] [cols="1"] |=== -a| *SDPi Supplement Version Note*: The content in the IHE PCD 2019 TF-3 3.1 section will need to be edited to be agnostic to the underlying protocol, with protocol specifics being relegated to subsections in <> below. +a| *SDPi Supplement Version Note*: The content in the IHE PCD 2019 TF-3 3.1 Section will need to be edited to be agnostic to the underlying protocol, with protocol specifics being relegated to subsections in <> below. |=== @@ -80,10 +80,10 @@ a| *SDPi Supplement Version Note*: The content in the IHE PCD 2019 TF-3 3.1 sect [%noheader] [cols="1"] |=== -| Move IHE PCD 2019 TF-3 sections 3.2 to 3.7 to this SDPi 1.1 TF-3 section 8.3.1.2 TO 8.3.1..7 +| Move IHE PCD 2019 TF-3 sections 3.2 to 3.7 to this SDPi 1.1 TF-3 Section 8.3.1.2 TO 8.3.1..7 -A new 8.3.1.1 section should be added to the Classic DIM content section that addresses basic reporting. -This content would be extracted from the existing (2019) section 3.1, where that content is specific to the Classi DIM (see related note above). +A new 8.3.1.1 Section should be added to the Classic DIM content section that addresses basic reporting. +This content would be extracted from the existing (2019) Section 3.1, where that content is specific to the Classi DIM (see related note above). |=== // 8.3.2 @@ -112,7 +112,7 @@ Though there are no PHD requirements in this supplement, there are PHD profiles [%noheader] [cols="1"] |=== -| Move IHE PCD 2019 TF-3 section 4 Reserved to this SDPi 1.1 TF-3 section 8.4 +| Move IHE PCD 2019 TF-3 Section 4 Reserved to this SDPi 1.1 TF-3 Section 8.4 |=== === RESERVED @@ -120,7 +120,7 @@ Though there are no PHD requirements in this supplement, there are PHD profiles [%noheader] [cols="1"] |=== -| Move IHE PCD 2019 TF-3 section 5 Reserved to this SDPi 1.1 TF-3 section 8.5 +| Move IHE PCD 2019 TF-3 Section 5 Reserved to this SDPi 1.1 TF-3 Section 8.5 |=== === RESERVED @@ -128,7 +128,7 @@ Though there are no PHD requirements in this supplement, there are PHD profiles [%noheader] [cols="1"] |=== -| Move IHE PCD 2019 TF-3 section 6 Reserved to this SDPi 1.1 TF-3 section 8.6 +| Move IHE PCD 2019 TF-3 Section 6 Reserved to this SDPi 1.1 TF-3 Section 8.6 |=== // 8.7