From c166523e33b33f400665ad9b06ba94dc0a086dfe Mon Sep 17 00:00:00 2001 From: "Todd \"AFC!\" Cooper" Date: Fri, 11 Oct 2024 06:34:50 -0700 Subject: [PATCH 01/16] Release 1.4.1 (#322) * Publication 1.4.1 Updates See log for integration of 1.4.0 review period updates. Editorial changes (typos, style corrections, etc.). * Updated release date --- CHANGELOG.md | 10 ++++++++++ asciidoc/sdpi-supplement.adoc | 4 ++-- .../tf1-ch-a-requirements-interoperability.adoc | 6 +++--- ...tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc | 0 4 files changed, 15 insertions(+), 5 deletions(-) rename asciidoc/volume3/{mdib-efficieny => mdib-efficiency}/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc (100%) diff --git a/CHANGELOG.md b/CHANGELOG.md index 719422a3..9faf88bc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,16 @@ Each section shall contain a list of action items of the following format: `> Section below.>. +. Requirement TYPEs are rooted in the layers that they represent and link type definitions to their use in this specification; see <> Section below. NOTE: The implementation of this high-level framework will be extended as the specifications and tooling mature. diff --git a/asciidoc/volume3/mdib-efficieny/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc b/asciidoc/volume3/mdib-efficiency/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc similarity index 100% rename from asciidoc/volume3/mdib-efficieny/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc rename to asciidoc/volume3/mdib-efficiency/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc From 5b0c9725924c7d23242fa6ca0bcae3befe45f47d Mon Sep 17 00:00:00 2001 From: Paul Martinsen Date: Wed, 13 Nov 2024 22:27:57 +1300 Subject: [PATCH 02/16] 292 example message has wrong action urn for waveform stream (#333) * Fix incorrect example action. * Updated change log. * Tidy for PR --- CHANGELOG.md | 3 +++ .../vol2-clause-appendix-a-mdpws-dev-29-waveformstream.xml | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9faf88bc..16968497 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,9 @@ Each section shall contain a list of action items of the following format: ` - http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/WaveformStream + http://standards.ieee.org/downloads/11073/11073-20701-2018/WaveformService/WaveformStream From babef76dae10b77d00d64b5429732bfc8e34b64a Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Mon, 18 Nov 2024 13:41:51 +0100 Subject: [PATCH 03/16] Resolution implemented (#335) * Resolution implemented * CHANGELOG updated --- CHANGELOG.md | 1 + .../tf3-ch-8.3.2.9-mdib-report-retrofit.adoc | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 16968497..ef99f1a1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -17,6 +17,7 @@ Each section shall contain a list of action items of the following format: `> shall not send msg:DescriptionModifi [%collapsible] ==== NOTE: This requirement simplifies processing of changes for a <> in a way that the <> can apply description modification changes one by one without additional consistency checks. If deletion and re-insertion of objects is needed, a <> sends out two description modification reports successively. + +NOTE: DEPRECATION NOTICE - This requirement is being incorporated into the IEEE 11073-10207 BICEPS standard through a corrigendum. Once IEEE has published the IEEE 11073-10207 BICEPS Corrigenda, this SDPi requirement will be no longer needed, and will hence be removed. ==== **** @@ -54,6 +56,8 @@ A <> shall order msg:DescriptionModificat [%collapsible] ==== NOTE: This explicitly requires to only communicate children as inserted if the parent has been inserted already, which simplifies insertion of descriptors on the <> side. + +NOTE: DEPRECATION NOTICE - This requirement is being incorporated into the IEEE 11073-10207 BICEPS standard through a corrigendum (albeit without the clarification note immediately above). Once IEEE has published the IEEE 11073-10207 BICEPS Corrigenda, this SDPi requirement will be no longer needed, and will hence be removed. ==== **** @@ -84,5 +88,7 @@ A <> shall communicate a parent descripto [%collapsible] ==== NOTE: Replaces biceps:R5046: "If a parent descriptor is deleted, then all child descriptors of that parent SHALL communicated as deleted in advance." + +NOTE: DEPRECATION NOTICE - This requirement is being incorporated into the IEEE 11073-10207 BICEPS standard through a corrigendum. Once IEEE has published the IEEE 11073-10207 BICEPS Corrigenda, this SDPi requirement will be no longer needed, and will hence be removed. ==== **** From b06b1de04fb41b707f52b636f09869cfb3632d51 Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Tue, 19 Nov 2024 17:16:50 +0100 Subject: [PATCH 04/16] Issue #274 resolution + CHANGELOG updates (#337) --- CHANGELOG.md | 6 +++++- asciidoc/sdpi-supplement-issues.adoc | 6 +++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ef99f1a1..d5d72efb 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,9 +15,13 @@ Each section shall contain a list of action items of the following format: ` Date: Wed, 20 Nov 2024 10:22:34 +0100 Subject: [PATCH 05/16] 275 hl7 2024 jan misc editorial review updates (#338) * Addressed 3 JIRA tickets listed in issue #275 * Addressed 3 JIRA tickets listed in issue #275 * Changelog update * debugging Changelog --- asciidoc/sdpi-supplement-intro.adoc | 8 ++++---- asciidoc/sdpi-supplement-issues.adoc | 2 +- ...-ch-c-conformance-statement-ieee-11073-10207-2017.adoc | 2 +- asciidoc/volume1/tf1-ch-10-sdpi-p.adoc | 6 +++--- asciidoc/volume1/tf1-ch-2-overview.adoc | 4 ++-- .../volume1/tf1-ch-a-requirements-interoperability.adoc | 4 ++-- asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc | 4 ++-- asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc | 6 +++--- .../volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc | 6 +++--- .../tf3-ch-8.3.2.9.5-extension-gender.adoc | 2 +- 10 files changed, 22 insertions(+), 22 deletions(-) diff --git a/asciidoc/sdpi-supplement-intro.adoc b/asciidoc/sdpi-supplement-intro.adoc index 931f05f2..349c4246 100644 --- a/asciidoc/sdpi-supplement-intro.adoc +++ b/asciidoc/sdpi-supplement-intro.adoc @@ -58,7 +58,7 @@ 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 +* General overview of the SDPi architectural approach and 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 @@ -96,7 +96,7 @@ These three objectives may be summarized as follows: [none] * *Requirements Interoperability (RI)* [none] -** Ability to integrate & automate requirements and capabilities from component specifications & standards to enable traceability & coverage at <> (<>) of the component product interface +** Ability to integrate and automate requirements and capabilities from component specifications and standards to enable traceability and coverage at <> (<>) of the component product interface * *Model Centric (MC)* [none] ** Transition from a document-centric to a _computable model-based "single source of truth"_ specification from which the Technical Framework becomes a view of the model @@ -105,10 +105,10 @@ These three objectives may be summarized as follows: ** Enable CA test reports that are genuinely _"regulatory submission ready"_ (e.g., inclusion in a U.S. FDA 510(k) submission package) The SDPi {ihe_supplement_sdpi_revision} version of the supplement continues to make small but significant steps toward support of these objectives, especially Requirements Interoperability, as well as the use of AsciiDoc metadata to annotate the document sources for post-processing. -Clearly, moving toward <> specifications and full integration of <> (<>) will take considerable effort and time; however, this supplement represents a humble start in that direction. +Clearly, moving toward <> specifications and full integration of <> will take considerable effort and time; however, this supplement represents a humble start in that direction. Subsequent supplement versions will build upon these objectives and support a new level of rigor for connectathon and product conformity assessment testing and ultimately test reports that directly impact the challenges around medical product regulatory submissions. -Additional discussion is provided in <>, and on the https://confluence.hl7.org/pages/viewpage.action?pageId=82906664#ConformityAssessment&Tooling-RI+MC+RRforMedTechSpecificationsInitiative[Gemini project's confluence pages]. +Additional discussion is provided in <>, and on the https://confluence.hl7.org/pages/viewpage.action?pageId=82906664#ConformityAssessment&Tooling-RI+MC+RRforMedTechSpecificationsInitiative[Gemini project's Confluence pages]. See also related discussions on the Gemini Project's https://confluence.hl7.org/x/XhPUB[Pathway to an Ecosystem of Plug-and-Trust Products]. diff --git a/asciidoc/sdpi-supplement-issues.adoc b/asciidoc/sdpi-supplement-issues.adoc index 5e3c1005..4041495e 100644 --- a/asciidoc/sdpi-supplement-issues.adoc +++ b/asciidoc/sdpi-supplement-issues.adoc @@ -12,7 +12,7 @@ Filter the issues on "Topic of Interest" to see a full list related to any "Topi * To see the full list of OPEN issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen+label%3A%22Topic+of+Interest%22 * To see the full list of CLOSED issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed+label%3A%22Topic+of+Interest%22 -For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#overview-from-discussion-to-planning-to-development[_Overview: From Discussion to Planning to Development_] and the confluence article https://confluence.hl7.org/pages/viewpage.action?pageId=82912211#TopicsofInterest-TopicResolutionWorkflow[_Topics of Interest -- Topic Resolution Workflow_]. +For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#overview-from-discussion-to-planning-to-development[_Overview: From Discussion to Planning to Development_] and the Confluence article https://confluence.hl7.org/pages/viewpage.action?pageId=82912211#TopicsofInterest-TopicResolutionWorkflow[_Topics of Interest -- Topic Resolution Workflow_]. [sdpi_offset=clear] === Open Issues and Topic of Interests 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 503abe68..bcb1c497 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 @@ -16,7 +16,7 @@ Requirement Definition (this table's rows) will be referenced where they are sat ===== General -WARNING: GEN-1 & GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions. +WARNING: GEN-1 and GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions. ADD IEEE: *Table 20 -- General ICSs table here* diff --git a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc index fef9736d..8d41360b 100644 --- a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc +++ b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc @@ -15,8 +15,8 @@ All the SDPi-P actors are therefore scoped with “<>” to clear Although all information exchanged between SDPi-P <> participating systems and applications must conform to the basic <>/<> content module requirements footnote:[See <>. ], content modules have been defined for common high-acuity medical devices such as infusion pumps, ventilators and physiologic monitors. -Note that future IHE _workflow profiles_ may be defined that build upon the transport & content module foundation established by the SDPi-P profile. -For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU & Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction. +Note that future IHE _workflow profiles_ may be defined that build upon the transport and content module foundation established by the SDPi-P profile. +For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU / Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction. [#vol1_clause_sdpi_p_actors_transactions_content_modules,sdpi_offset=1] @@ -27,7 +27,7 @@ For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Ca [cols="1"] |=== a| *{supplement_note}*: Some actors and transactions have been deferred to a subsequent version, but are included here for completeness. -Specifically: SOMDS FHIR Gateway, SOMDS Sensor Gateway & SOMDS Smart App Platform, have been deferred. +Specifically: SOMDS FHIR Gateway, SOMDS Sensor Gateway and SOMDS Smart App Platform, have been deferred. Deferred transactions have been so indicated in the transactions table. diff --git a/asciidoc/volume1/tf1-ch-2-overview.adoc b/asciidoc/volume1/tf1-ch-2-overview.adoc index 3db54e63..7471eaf3 100644 --- a/asciidoc/volume1/tf1-ch-2-overview.adoc +++ b/asciidoc/volume1/tf1-ch-2-overview.adoc @@ -202,12 +202,12 @@ Given the significant risks associated with allowing device-external control fun | <> | Device Enterprise Communication (DEC)) | The <> integrates DEC Device Observation Reporter (DOR) Actor specifications. -| Required for mapping from <> & <> to HL7 V2 and DEC transactions. +| Required for mapping from <> and <> to HL7 V2 and DEC transactions. | <> | Alert Communication Management (ACM) | The <> integrates ACM Alert Reporter (AR) Actor specifications. -| Required for mapping from <> & <> to HL7 V2 and ACM transactions. +| Required for mapping from <> and <> to HL7 V2 and ACM transactions. |=== diff --git a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc index 0b85cb29..b3a2905c 100644 --- a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc +++ b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc @@ -52,7 +52,7 @@ NOTE: The implementation of this high-level framework will be extended as the s [#vol1_appendix_a_integrating_ses] === Integrating Safety, Effectiveness and Security Requirements and Considerations -In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched -- Joint Working Group 7 (JWG7) -- to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned & managed) networking infrastructure. +In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched -- Joint Working Group 7 (JWG7) -- to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned and managed) networking infrastructure. The resulting standard, <>, with a first edition published in 2010 and revised in 2021, not only provided a process for performing coordinated multi-stakeholder risk management for these technologies, but recognized the three *key properties* that would be the focus of that risk management: *_Safety, Effectiveness & Security (SES)_* footnote:ses_definitions[For definitions of these and other related terms, consult the https://81001.org[NHS 81001.org web page.] Last accessed 2022.10.04.]. During the development of the 80001-1 standard, though, it was recognized that risk management is just one of a number of other core themes that had to be managed in concert (e.g., quality management, human factors / usability). @@ -65,7 +65,7 @@ image::../images/vol1-diagram-81001-temple.svg[algin=center] . Source: <> One of the key challenges for implementing this standard, though, is what might be labeled: *_The Interoperability Trust Gap_*. -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). +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 and 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: diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc index 745db6ec..ae5a2749 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc @@ -150,7 +150,7 @@ A <> shall set the OBR-4 field to *"196616\^MDC_EVT_ALA .R8055 [sdpi_requirement#r8055,sdpi_req_level=shall] **** -A <> shall set the OBR-7 field to the date & time at which the Alert Reporter (AR) of the IHE ACM gateway created the alert event message to be sent. +A <> shall set the OBR-7 field to the date and time at which the Alert Reporter (AR) of the IHE ACM gateway created the alert event message to be sent. .Notes [%collapsible] @@ -355,7 +355,7 @@ 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). +NOTE: The HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (please refer to <> for further information). ==== **** diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc index e6860cd8..6e8c5058 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc @@ -143,7 +143,7 @@ When there are further updates of the height value after the association of the |OBX-14 |Date/Time of the Observation |pm:PatientContextState++++++/@BindingStartTime -|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). +|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). |=== @@ -232,7 +232,7 @@ When there are further updates of the weight value after the association of the |OBX-14 |Date/Time of the Observation |pm:PatientContextState++++++/@BindingStartTime -|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). +|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). |=== @@ -784,7 +784,7 @@ NOTE: <> defines the mapping of the SDC metric measur pm:NumericMetricState++++++/pm:MetricValue++++++/@DeterminationTime pm:StringMetricState++++++/pm:MetricValue++++++/@DeterminationTime -|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). +|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). |=== 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 4e679c6d..af3416a0 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc @@ -175,7 +175,7 @@ NOTE: <> defines the mapping of the SDC patient name infor .R8106 [sdpi_requirement#r8106,sdpi_req_level=shall,sdpi_max_occurrence=1] **** -If <> is met, then a <> / <> shall set the PID-7 field to the date & time of birth. +If <> is met, then a <> / <> shall set the PID-7 field to the date and time of birth. .Notes [%collapsible] @@ -192,7 +192,7 @@ NOTE: <> defines the mapping of the SDC patient's date of |PID-7/DTM-1 |Date/Time |pm:PatientContextState++++++/pm:CoreData++++++/pm:DateOfBirth -|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). +|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). |=== @@ -305,7 +305,7 @@ When there are further updates of the sex value after the association of the pat |OBX-14 |Date/Time of the Observation |pm:PatientContextState++++++/@BindingStartTime -|Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). +|Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also <>). |=== diff --git a/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-gender.adoc b/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-gender.adoc index 19ac3186..7357b051 100644 --- a/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-gender.adoc +++ b/asciidoc/volume3/biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-gender.adoc @@ -6,7 +6,7 @@ [cols="1"] |=== a| *{supplement_note}*: As mentioned in the main text below, <> does not currently provide sex and gender semantic support at the same level of detail as foundational existing and emerging standards. -The following sex & gender harmonization policy will be taken in this and future SDPi specification versions until clear direction is available. +The following sex and gender harmonization policy will be taken in this and future SDPi specification versions until clear direction is available. [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. From 5b03274b7f57e77624c91626508f4ba2e4258bd7 Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Wed, 20 Nov 2024 14:09:21 +0100 Subject: [PATCH 06/16] 317 probematch behaviour potentially inconsistent (#339) * Added note to DEV-47 to clarify behavior * Changelog update * Added note to DEV-47 to clarify behavior * Changelog update * Changelog update - 2nd attempt * Changelog update - 2nd attempt * Added note to DEV-47 to clarify behavior * Changelog update * Changelog update - 2nd attempt * Changelog update * debugging Changelog * Added note to DEV-47 to clarify behavior * Changelog update * Changelog update - 2nd attempt * Changelog update * Changelog update - 2nd attempt * Changelog update * debugging Changelog --- CHANGELOG.md | 4 ++++ asciidoc/volume2/dev-47/tf2-dev-47.adoc | 2 ++ 2 files changed, 6 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index d5d72efb..8a950976 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -17,12 +17,16 @@ Each section shall contain a list of action items of the following format: `> receives a <> message that contains a <> that matches zero or more <>'s <>s. +NOTE: The <> always responds to the <> message of the <> with a <> message, even when there are zero <> matches. Thus, the <> can always recognize whether the <> has completed the transaction. This is possible in this transaction because of the non-multicast nature of its <> and <> messages. The behavior is different in the <> transaction, which uses multicast messaging. + [#vol2_clause_dev_47_message_probe_match_semantics] ====== Message Semantics From 33d881646f4bf14d19cdb2cfe2c97c27f5d9aece Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Fri, 22 Nov 2024 13:29:01 +0100 Subject: [PATCH 07/16] Corrected some entries in "1:B.1 Referenced Standards" for consistency (#341) --- CHANGELOG.md | 3 +- .../tf1-ch-b-ref-standards-conformance.adoc | 36 +++++++++---------- 2 files changed, 19 insertions(+), 20 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 8a950976..6f027606 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,10 +23,9 @@ Each section shall contain a list of action items of the following format: ` Date: Fri, 6 Dec 2024 16:41:21 +0100 Subject: [PATCH 08/16] Commented out concept sections 1:10.4.1.3 thru 1:10.4.1.10 and minimized referencing to years for improving readability (#345) --- CHANGELOG.md | 1 + asciidoc/sdpi-supplement-intro.adoc | 2 +- asciidoc/volume1/tf1-ch-10-sdpi-p.adoc | 43 ++++++++++++++----------- asciidoc/volume1/tf1-ch-11-sdpi-r.adoc | 4 +-- asciidoc/volume1/tf1-ch-12-sdpi-a.adoc | 4 +-- asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc | 2 +- asciidoc/volume1/tf1-ch-2-overview.adoc | 2 +- 7 files changed, 33 insertions(+), 25 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 6f027606..210f8592 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -24,6 +24,7 @@ Each section shall contain a list of action items of the following format: `>), some of which are finalized and published and others that are either being developed or in revision. -For example, the IEEE 11073-10702 PKP standard is in development with balloting expected late 2024 and publication mid-2025; however, some requirements from that pre-standard may be included in this SDPi specification, providing a pathway to early experience and validation. +For example, the IEEE 11073-10702 PKP standard is in mature development stage; however, some requirements from that pre-standard may be included in this SDPi specification, providing a pathway to early experience and validation. When a referenced specification is used that is in development or revision, a note will be provided in the <> clearly indicating its status. It is recognized that this release is a work-in-progress that will continue to subsequent versions. diff --git a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc index 8d41360b..8d344093 100644 --- a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc +++ b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc @@ -455,8 +455,10 @@ 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. @@ -541,9 +543,9 @@ For example, an application may only need to identify and consume a few paramete Since a single platform actor can support multiple Smart Apps, network traffic may be significantly reduced, as well as processing overhead for <> systems that have multiple <>s simultaneously invoking their services. The platform must support both non-smart app critical functions (such as network topology discovery and maintenance) but also aggregate app requirements (e.g., quality of service necessary to support an application’s algorithms). - +//// See <> for additional discussion. - +//// ===== BICEPS Content Creator [#vol1_spec_sdpi_p_actor_biceps_content_creator, reftext='BICEPS Content Creator'] Actor Summary Definition: @@ -821,6 +823,7 @@ To support the <>-based connectivity described above, the *_default Additional "glue" constraints for this <> specification are provided in the companion standard: <>. Specific <> transaction message bindings and examples are provided in <>. +//// ===== General Healthcare vs. Medical Interoperability Purposes [%noheader] @@ -829,11 +832,11 @@ Specific <> transaction message bindings and |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// #TODO: All the transactions here are focused on healthcare information exchange with out any intended medical purpose; relationship to the other SDPi Profiles# //// - +//// [#vol1_clause_sdpi_p_ensuring_time_synchronization] ===== Ensuring Time Synchronization @@ -843,14 +846,14 @@ a| *{supplement_note}*: This section intentionally left blank for the current v |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// #TODO: This is a key topic for all health information exchange, and especially that of medical data. A consuming system has to know, for example, that the time stamps provided in the BICEPS content or in the messages is accurate (and to what degree). Requirements will be included HERE for SOMDS Participant & all other actors including BICEPS Content . Additional requirements may be added to the TF-3 BICEPS Content Module section as well. Integration of CT and ATNA (TBD) below in required groupings is assumed but should be detailed here.# #TODO: No time sync service identified in 11073 SDC core; include only in the SDPi-P section ... as a requirement to use NTP?; reference resolution of *TS Service*, *MD LAN*, in glossary entries# //// - +//// ===== Waveform Communication [%noheader] @@ -859,11 +862,11 @@ Integration of CT and ATNA (TBD) below in required groupings is assumed but shou |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// #TODO: Explain how waveforms are communicated, both snippets and especially "streaming"; include references to appropriate TF-2 & TF-3 Sections; this is part of the "DO WE NEED A WAVEFORM OPTION?" question to help end users? NO!!! Could drop a note in TF-2 Appendix A for DEV-xyz and how RTSA/Waves would be transmitted / conveyed over the network# //// - +//// [#vol1_clause_sdpi_p_aggregators_proxies_sensors] ===== Aggregators, Proxies, Sensors @@ -873,7 +876,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// ##TODO: : Include single / multiple patient variations. See Topic on confluence; ultimately probably in TF-1 & -2 & -3. NOTE added a section in TF-3 as well. Mention SENSORS and WSN referencing SOMDS Sensor Gateways w/ rationale. @@ -882,7 +885,7 @@ NOTE: This is not defined in 11073-20701 beyond clause 3. Definitions See Gateways in the actors discussion above … and below? ## //// - +//// ===== Protocol-Specific Gateways [%noheader] @@ -891,12 +894,12 @@ See Gateways in the actors discussion above … and below? |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// #TODO: : External interfaces “gateways” defined in the abstract and in the protocol-specific. These actors are leveraged in other profiles such as SDPi-Reporting for a DEC Gateway or in SDPi-Alerting for an ACM gateway. Include proprietary protocols as well. Given the discussion in Actors above, is this necessary here? Or should some of that content be moved here? YES … show examples for how the Actors might be grouped into a real-world gateway to … for example … an EHR etc.]# //// - +//// [#vol1_clause_smart_app_platforms] ===== Smart App Platforms @@ -906,11 +909,11 @@ Given the discussion in Actors above, is this necessary here? Or should some of |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// #TODO: 1. This section enhances the short actor description above to describe in more detail the various aspects of an application “platform”; see Word draft Section 10.4.1.5 for additional content# //// - +//// ===== Workflow vs. Transport Actors and Interactions [%noheader] @@ -919,7 +922,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v |=== a| *{supplement_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== - +//// //// #TODO: discuss the challenges of drawing a line between transport profile actors in SDPi and applications of those actors in more care context / workflow applications, such as Smart Alarming or MDIRA/ICE or ICU Integration etc. Reference General Introduction profile "types" - workflow vs. transport vs. content (???) ]# //// @@ -952,7 +955,11 @@ 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 diff --git a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc index af658cdf..f5b4d6bd 100644 --- a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc +++ b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc @@ -8,8 +8,8 @@ [cols="1"] |=== a| *{supplement_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 <> 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 / 2024_*, their requirements will be integrated into this supplement, with their <> added to <> below. +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 full integration of two emerging ISO/IEEE standards: <> and <>. +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 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. diff --git a/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc b/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc index 2213708a..960dec08 100644 --- a/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc +++ b/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc @@ -9,7 +9,7 @@ |=== a| *{supplement_note}*: This initial version of the <> Profile is built upon the foundational <> Profile but adds services specialized for the communication and management of medical device alerting. Additionally, since the primary purpose of this specification is the communication of medical alert information to accomplish intended medical purposes, it will require the completion and integration of the emerging ISO/IEEE 11073 Alert <> standard <>. -When this new standard is published *_in 2024_*, its requirements will be integrated into this supplement, with its <> added to <>. +When this new standard is published, 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 <>. @@ -18,7 +18,7 @@ As a result, the completion of these two transactions has been deferred to a sub Similarly, a related transaction, [DEV-43], namely providing clinician alert acknowledgement status information back to the alerting device, is also being discussed further and will be deferred to a subsequent version of the supplement. Finally, it should be noted that <> 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. +Also in development is <> <> support for medical alerting (e.g., refinement of the <> DeviceAlert resource). As a result, a "SOMDS Medical Alert FHIR Gateway" is not included as an actor at this stage; however, it is expected to be added in the coming year or two. |=== diff --git a/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc b/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc index 83c2a681..1e3daeb9 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| *{supplement_note}*: This SDPi-xC (External Control) Profile Section is generally out-of-scope for this version of the profile (see https://github.com/orgs/IHE/projects/6/views/1["Gemini SDPi Releases" Github project]); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided in 2024 as part of the 1.x or 2.0 versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading). +a| *{supplement_note}*: This SDPi-xC (External Control) Profile Section is generally out-of-scope for this version of the profile (see https://github.com/orgs/IHE/projects/6/views/1["Gemini SDPi Releases" Github project]); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided as part of the 2.X or 3.X versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading). |=== diff --git a/asciidoc/volume1/tf1-ch-2-overview.adoc b/asciidoc/volume1/tf1-ch-2-overview.adoc index 7471eaf3..069f4c2e 100644 --- a/asciidoc/volume1/tf1-ch-2-overview.adoc +++ b/asciidoc/volume1/tf1-ch-2-overview.adoc @@ -145,7 +145,7 @@ Profile options are provided for additional capabilities that may be required to [sdpi_offset=12] ==== Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile The SDPi Alerting Profile builds on the basic <> 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 2024). +To that end, this specification implements the safety and security requirements of the <> alert <> standard (expected to be completed in 2025). The profile supports core medical alerting functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., alert delegation). From 5e40d53df90e543a7772f22b5c41d32d53fa3be2 Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Fri, 6 Dec 2024 17:11:35 +0100 Subject: [PATCH 09/16] 264 hl7 2024 jan clarify fhir gateway actor support for multiple paradigms (#348) * First draft to resolve issue #264 * First draft to resolve issue #264 * Added CHANGELOG entry for issue #264 --- CHANGELOG.md | 1 + asciidoc/volume1/tf1-ch-10-sdpi-p.adoc | 7 ++++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 210f8592..7a8099b1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,7 @@ Each section shall contain a list of action items of the following format: `> and / or The <> actor identifies and specifies the logic necessary for connecting a SOMDS network environment with Non-SOMDS Systems that utilize <> for their interoperability protocol. Generally, this logic is defined in the HL7 <>. -Gateways implementing this actor can support any of the FHIR architectural approaches: RESTful, messaging, documents, and SOA. -For example, a <> can utilize a <> to retrieve information from other _<>_ systems, map it into FHIR Bundle resources and forward it on to non-SOMDS systems in a FHIR message. +Gateways implementing this actor can generally support any of the FHIR architectural approaches: RESTful, messaging, documents, and SOA - although the primary approaches are RESTful and messaging. A specific <> specification in <> will constrain to (a) specific approach(es). To facilitate interoperability, named options may be added to specialized actors to clearly indicate what a given implementation supports. + +For example, a <> could utilize a <> to retrieve information from other _<>_ systems, map it into FHIR Bundle resources and forward it on to non-SOMDS systems in a FHIR message. Alternatively, the <> could implement a FHIR server and provide support for systems to discover and retrieve information asynchronously, including the use of FHIR publication / subscription (“pub/sub”) services. -The <> can also support SOMDS services invoked by FHIR-based systems, such as requesting a snapshot of the latest vital signs measurements for a specific patient and triggering a blood-pressure cuff reading. +The <> could also support SOMDS services invoked by FHIR-based systems, such as requesting a snapshot of the latest vital signs measurements for a specific patient and triggering a blood-pressure cuff reading. [#vol1_clause_sdpi_p_somds_v2_gateway] ===== SOMDS V2 Gateway From 2095d0181735cb327323bbcd20107169e2721100 Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Fri, 6 Dec 2024 17:28:46 +0100 Subject: [PATCH 10/16] 273 hl7 2024 jan resolve or remove tbd statements from text (#349) * Resolution of issue #273 as discussed * Added CHANGELOG entry for issue #273 --- CHANGELOG.md | 1 + asciidoc/volume0/tf0-ch-a-actors.adoc | 10 +++------- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 7a8099b1..d9af5c3a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -26,6 +26,7 @@ Each section shall contain a list of action items of the following format: ` Date: Mon, 9 Dec 2024 02:55:29 -0800 Subject: [PATCH 11/16] SES Non-Comprehensive Note Added (#351) * SES Non-Comprehensive Note Added A note was added to section 1:2.2 to indicate that the SES sections in the document are not intended to represent comprehensive risk management requirements and that implementers must ensure that appropriate RM processes have been completed. * Simple formatting update Highlighted the primary point of the HL7 ballot comment. --- CHANGELOG.md | 1 + asciidoc/volume1/tf1-ch-2-overview.adoc | 3 +++ 2 files changed, 4 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index d9af5c3a..9da593c1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -19,6 +19,7 @@ Each section shall contain a list of action items of the following format: `>. Generally, requirements from these standards would be mapped to the appropriate "Safety, Effectiveness and Security - Requirements and Considerations" sections throughout the specification. +NOTE: The *_SES sections in this document are not intended to be comprehensive_*, but provide helpful guidance to risk managers. +Implementers must ensure that all appropriate risk management processes have been performed. + // 2.3 [#vol1_clause_integration_profiles_overview] === Integration Profiles Overview From a64ee6012b9528581c96b164be1e9e498dc9236d Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Fri, 13 Dec 2024 15:41:09 +0100 Subject: [PATCH 12/16] 263 hl7 2024 jan expand explanation of how use cases are integrated into the specification (#355) * Added new Use Case Description section to the Supplement Introduction New section added to Supplement Introduction: Use Cases: Mapping Clinical Scenarios to Profile Requirements * Added new Use Case Description section to the Supplement Introduction New section added to Supplement Introduction: Use Cases: Mapping Clinical Scenarios to Profile Requirements --------- Co-authored-by: Todd "AFC!" Cooper --- CHANGELOG.md | 1 + asciidoc/sdpi-supplement-intro.adoc | 12 ++++++++++++ 2 files changed, 13 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9da593c1..a89fdf0c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,7 @@ Each section shall contain a list of action items of the following format: `> provides a collection of these high-level clinical use cases. + +FOR READERS OF THIS SUPPLEMENT, a good strategy might be to first review the use cases in the Volume 1 appendix (e.g., <> ), and then review the specific profiles to which the clinical scenario requiremets have been mapped. +Reviewing the use case specifications in this order will provide the needed context to understand what is presented in each profile. + [#supplement_clause_joint_ihe_hl7_gemini_ses_mdi_project_development] === Joint IHE-HL7 Gemini SES+MDI Project Development This supplement is the result of a joint https://confluence.hl7.org/x/Xzf9Aw[IHE-HL7 Gemini Device Interoperability program] which began early 2020. From 18c5ef725846915387818aca28de4ab7d93bb477 Mon Sep 17 00:00:00 2001 From: "Todd \"AFC!\" Cooper" Date: Fri, 13 Dec 2024 06:44:57 -0800 Subject: [PATCH 13/16] Updated Rational for Bibliography subsections (#352) * Updated Rational for Bibliography subsections General rationale provided at the beginning of the section with scope statements for each of the three subsections. NOTE: Not added was anything related to the fact that it may change in the future if someone has a big idea and the energy to make the change. * Updated Rational for Bibliography subsections General rationale provided at the beginning of the section with scope statements for each of the three subsections. NOTE: Not added was anything related to the fact that it may change in the future if someone has a big idea and the energy to make the change. --------- Co-authored-by: JavierEspina --- CHANGELOG.md | 1 + asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc | 8 ++++++++ 2 files changed, 9 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index a89fdf0c..ade8dc95 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,7 @@ Each section shall contain a list of action items of the following format: ` Date: Fri, 13 Dec 2024 15:50:48 +0100 Subject: [PATCH 14/16] 276 hl7 2024 jan enhance explanation of soa aspects of the sdcsdpi specification (#356) * Updated description of SOA applied to MDI ChangeLog entry for #276 References added to Bibliography section TF-1B Updated content added to 1:10.4.1.1 SOA & SOMDS Architecture Alignment * Updated description of SOA applied to MDI ChangeLog entry for #276 References added to Bibliography section TF-1B Updated content added to 1:10.4.1.1 SOA & SOMDS Architecture Alignment * Corrected CHANGELOG conflict (by rebasing onto master) * Updated description of SOA applied to MDI ChangeLog entry for #276 References added to Bibliography section TF-1B Updated content added to 1:10.4.1.1 SOA & SOMDS Architecture Alignment * Corrected CHANGELOG conflict (by rebasing onto master) --------- Co-authored-by: Todd "AFC!" Cooper --- CHANGELOG.md | 2 ++ asciidoc/volume1/tf1-ch-10-sdpi-p.adoc | 7 ++++++- asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc | 6 ++++++ 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ade8dc95..b8a6ed99 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,8 @@ Each section shall contain a list of action items of the following format: `> concepts is beyond the scope of this specification. See <> for additional background materials. +As SOA concepts and implementations have evolved, many different approaches have been defined, building upon some of the basic principles (as listed above) and adding detail appropriate for their specific application use. +A detailed overview of <> concepts is beyond the scope of this specification; however, a number of foundational references related to how SOA has been leveraged for medical device interoperability have been provided in <>, including: + +. <> +. <> +. <> The <> <> standard, which SDPi-P profiles, consists of (3) core components, as illustrated in <>: diff --git a/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc b/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc index 993eac33..9de67842 100644 --- a/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc +++ b/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc @@ -147,8 +147,14 @@ metalanguage - Extended BNF, 15 December 1996, available at https://standards.is * [[[ref_omg_sysml_2_0_intro_graphical_model,OMG SysML ^®^ Intro-Graphical Notation 2.0]]] OMG Systems Modeling Language™ (SysML^®^), Version 2.0, Introduction to the Graphical Model, Object Management Group (OMG) standard. Available at https://github.com/Systems-Modeling/SysML-v2-Release/tree/master/doc[github.com/Systems-Modeling/SysML-v2-Release/doc/] * [[[ref_omg_sysml_2_0_spec,OMG SysML ^®^ 2.0]]] OMG Systems Modeling Language ™ (SysML^®^), Version 2.0, Object Management Group (OMG) specification. Available at https://github.com/Systems-Modeling/SysML-v2-Release/tree/master/doc[github.com/Systems-Modeling/SysML-v2-Release/doc/] + * [[[ref_gender_harmony_project, HL7-GENDER]]] HL7 gender harmony project, available at https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project +* [[[ref_paper_connecting_clinical_it_to_soa_arch_of_medical_devices, Connecting the clinical IT infrastructure to a service-oriented architecture of medical devices]]] Paper reviewing use of SOA architecture to integrate medical devices into clinical IT infrastructure, available at https://pubmed.ncbi.nlm.nih.gov/29272252/ + +* [[[ref_ornet_soa_for_safe_dynamic_medical_device_interoperability, OR.NET: a service-oriented architecture for safe and dynamic medical device intoperability]]] Paper reviewing use of SOA architecture to enable an interoperable and safe ecosystem of medical devices, available at https://pubmed.ncbi.nlm.nih.gov/29346114/ + +* [[[ref_paper_design_pattern_for_soa_integration_of_medical_devices,Standardized Device Services - A Design Pattern for Service Oriented Integration of Medical Devices]]] C. Mauro, A. Sunyaev, J. M. Leimeister, and H. Krcmar, 2010 43rd Hawaii International Conference on System Sciences, Honolulu, HI, USA: IEEE, Jan. 2010, pp. 1–10. doi: 10.1109/HICSS.2010.347. [bibliography] ==== Presentations From 9799e1d403c29304feb4ec1fc4fd449ce48ae258 Mon Sep 17 00:00:00 2001 From: Peter Kranich <33724235+PeterKranich@users.noreply.github.com> Date: Fri, 13 Dec 2024 16:14:57 +0100 Subject: [PATCH 15/16] Added SDPi FHIR Gateway with the reference to the HL7 FHIR PoCD IG. (#343) * Added SDPi FHIR Gateway with the reference to the HL7 FHIR PoCD IG. * Added missing CHANGELOG entry (after merging with current master) --------- Co-authored-by: JavierEspina Co-authored-by: Todd "AFC!" Cooper --- CHANGELOG.md | 2 ++ asciidoc/volume1/tf1-ch-12-sdpi-a.adoc | 2 +- .../volume2/gateways/tf2-ch-b-gateway-fhir.adoc | 13 +++++++++++++ asciidoc/volume2/tf2-ch-b-gateways.adoc | 3 +++ 4 files changed, 19 insertions(+), 1 deletion(-) create mode 100644 asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc diff --git a/CHANGELOG.md b/CHANGELOG.md index b8a6ed99..92a25926 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -33,6 +33,8 @@ Each section shall contain a list of action items of the following format: `> 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 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 <>. diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc new file mode 100644 index 00000000..75f6173a --- /dev/null +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc @@ -0,0 +1,13 @@ +[#vol2_clause_appendix_sdpi_fhir_gateway] +=== SDPi FHIR Gateway +==== Scope +This chapter defines the mapping from the <> content as defined in this document and its underlying standards, to <> <> resources. + +The <> represents a <> data and/or alert reporter, which is defined in the <>. + +The section https://build.fhir.org/ig/HL7/uv-pocd/mappingsdc.html[SDC to FHIR Mapping] of the <> details the mapping from the <> content to <> <> resources. + +==== Referenced Standards & Profiles +This section provides an overview about the referenced standards and profiles used in this chapter: + +* <> diff --git a/asciidoc/volume2/tf2-ch-b-gateways.adoc b/asciidoc/volume2/tf2-ch-b-gateways.adoc index d14086c3..4d139f9a 100644 --- a/asciidoc/volume2/tf2-ch-b-gateways.adoc +++ b/asciidoc/volume2/tf2-ch-b-gateways.adoc @@ -17,4 +17,7 @@ include::gateways/tf2-ch-b-gateway-dec.adoc[] // Gateway: IHE DEV / PCD ACM Profile include::gateways/tf2-ch-b-gateway-acm.adoc[] +// Gateway: HL7 FHIR General Mappings +include::gateways/tf2-ch-b-gateway-fhir.adoc[] + From 929c1e3930d59598ad4cf9c38819478b2cae4acd Mon Sep 17 00:00:00 2001 From: Javier Espina <47562907+JavierEspina@users.noreply.github.com> Date: Fri, 13 Dec 2024 16:29:21 +0100 Subject: [PATCH 16/16] 269 hl7 2024 jan review ihe style conventions regarding numbers in text use of em dashes punctuation quotation marks etc (#357) * Corrected use of bracketed numbers throughout & removed em-dash after "4 Profiles" * Revised throughout punctuation with quotation marks - expect when specifying field content * Update CHANGELOG.md Updated per 2024.12.13 SDPi Friday review --------- Co-authored-by: Todd "AFC!" Cooper --- CHANGELOG.md | 1 + asciidoc/sdpi-supplement-intro.adoc | 6 +++--- asciidoc/volume0/tf0-ch-d-glossary.adoc | 2 +- asciidoc/volume1/tf1-ch-10-sdpi-p.adoc | 4 ++-- asciidoc/volume1/tf1-ch-11-sdpi-r.adoc | 2 +- asciidoc/volume1/tf1-ch-2-overview.adoc | 8 ++++---- asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc | 4 ++-- 7 files changed, 14 insertions(+), 13 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 92a25926..53280b31 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -32,6 +32,7 @@ Each section shall contain a list of action items of the following format: `>, including 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 future versions; @@ -47,14 +47,14 @@ include::document-declarations.adoc[] [#supplement_clause_sdpi_supplement_organization] === SDPi Supplement Organization -This IHE Devices Technical Framework supplement introduces a new _family of interoperability profiles_, Service-oriented Device Point-of-care Interoperability (SDPi), that comprise (4) separate profiles: +This IHE Devices Technical Framework supplement introduces a new _family of interoperability profiles_, Service-oriented Device Point-of-care Interoperability (SDPi), that comprise four separate profiles: * SDPi-Plug-and-trust (*SDPi-P*) Profile * SDPi-Reporting (*SDPi-R*) Profile * SDPi-Alerting (*SDPi-A*) Profile * SDPi-external Control (*SDPi-xC*) Profile -To that end, the supplement includes updates to all (3) IHE DEV TF volumes, including: +To that end, the supplement includes updates to all three IHE DEV TF volumes, including: *TF-1 Profiles* diff --git a/asciidoc/volume0/tf0-ch-d-glossary.adoc b/asciidoc/volume0/tf0-ch-d-glossary.adoc index 4719cf74..6c4375da 100644 --- a/asciidoc/volume0/tf0-ch-d-glossary.adoc +++ b/asciidoc/volume0/tf0-ch-d-glossary.adoc @@ -326,7 +326,7 @@ elements, from requirements to system components to Verification & Validation te | SDC | [[term_service_oriented_device_poc_interoperability,Service-oriented Device Point of Care Interoperability (SDPi)]] Service-oriented Device Point of Care Interoperability -| A set of (4) IHE specifications that profile the <> standards for device-to-device plug-and-play interoperability. +| A set of four IHE specifications that profile the <> standards for device-to-device plug-and-play interoperability. | | [[acronym_sdpi,SDPi]] SDPi | diff --git a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc index 92631bbc..ffd22e83 100644 --- a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc +++ b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc @@ -779,7 +779,7 @@ From a conceptual perspective, <> implements a <> arch [#figure_general_soa_model] image::../images/vol1-diagram-sdc-soa-conceptual-model.svg[align=center] -This generalized model includes (3) system roles: +This generalized model includes three system roles: . *Service Providers* -- indicate the capabilities or services that they support, often published to a centralized registry that all participating systems recognize; @@ -804,7 +804,7 @@ A detailed overview of <> concepts is beyond the scope of this spec . <> . <> -The <> <> standard, which SDPi-P profiles, consists of (3) core components, as illustrated in <>: +The <> <> standard, which SDPi-P profiles, consists of three core components, as illustrated in <>: .SDC/BICEPS Components Model [#figure_sdc_biceps_components_model] diff --git a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc index f5b4d6bd..dd4806c8 100644 --- a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc +++ b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc @@ -107,7 +107,7 @@ image::../images/vol1-diagram-sdpi-r-actor.svg[] | <> 5+<| -Note 1: If the <> implements the <>, then bidirectional exchange is supported and the roles are expanded to "Initiator & Responder". +Note 1: If the <> implements the <>, then bidirectional exchange is supported and the roles are expanded to "Initiator & Responder." |=== diff --git a/asciidoc/volume1/tf1-ch-2-overview.adoc b/asciidoc/volume1/tf1-ch-2-overview.adoc index 77441ef8..8257ff68 100644 --- a/asciidoc/volume1/tf1-ch-2-overview.adoc +++ b/asciidoc/volume1/tf1-ch-2-overview.adoc @@ -12,7 +12,7 @@ a| *{supplement_note}*: This supplement is being written after the 2019 reorgani It is intended to amend a new IHE DEV Technical Framework (TF), that covers the expanded areas not only of PCD devices (enterprise integration focused), but also Personal Connected Health (*PCH*) devices and Device Point-of-care Interoperability (*DPI*) for device-to-device integration around an acute point-of-care (e.g., operating room table, ICU bed, emergency department bed, etc.). 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(s) for General IHE Devices architecture, use contexts, and four <> 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.) These general concepts will help the technical framework reader understand the broader context into which the profile specifications are intended to be implemented. @@ -81,7 +81,7 @@ The SDPi Profiles are built upon a foundation of standards and profiles from <> that resulted in the definition of (4) profiles and not one: +There is a particular challenge with SDPi profiling of <> that resulted in the definition of four profiles and not one: [none] . *__How to represent a <>-based architecture supporting an interactive <> device-to-device (multi-way, M:N) interoperability specification using established IHE technical framework constructs? __* @@ -94,7 +94,7 @@ Or IHE "gateway" actors include mappings to the foundational, non-SDC standards. The above figure illustrates how this balance was achieved, including: [none] -. *4 Profiles* -- +. *Four Profiles* [none] .. 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* @@ -110,7 +110,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 four Profiles, which together provide a practical, pragmatic way toward genuine <> interoperability: [none] . P -> SDPi-Plug-and-trust diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc index ae5a2749..84967160 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc @@ -337,7 +337,7 @@ NOTE: The mapping differs for physiological alert events and technical/advisory [sdpi_requirement#r8077,sdpi_req_level=shall] **** -A <> shall report the Alert Event Phase as "update", when there are more updates than just the Alert Priority as specified in <> for the "update" Alert Event Phase. +A <> shall report the Alert Event Phase as "update" when there are more updates than just the Alert Priority as specified in <> for the "update" Alert Event Phase. **** @@ -770,7 +770,7 @@ OBX|6|ST|68481\^MDC_ATTR_EVENT_PHASE^MDC|1.1.1.1.3|start||||||R [sdpi_requirement#r8078,sdpi_req_level=shall] **** -A <> shall report the Alert Event Phase as "update", when there are more updates than just the Alert Priority as specified in <> for the "update" Alert Event Phase. +A <> shall report the Alert Event Phase as "update" when there are more updates than just the Alert Priority as specified in <> for the "update" Alert Event Phase. ****