diff --git a/.ci/asciidoc-converter/build_standard.bat b/.ci/asciidoc-converter/build_standard.bat new file mode 100644 index 00000000..a01e9840 --- /dev/null +++ b/.ci/asciidoc-converter/build_standard.bat @@ -0,0 +1,3 @@ +mkdir ..\..\sdpi-documents +mkdir ..\..\sdpi-documents\sdpi-standard +gradlew.bat run --args="--input-file ../../asciidoc/sdpi-standard.adoc --output-folder ../../sdpi-documents/sdpi-standard --backend html" diff --git a/.ci/asciidoc-converter/build_standard_debug.bat b/.ci/asciidoc-converter/build_standard_debug.bat new file mode 100644 index 00000000..b3249e1d --- /dev/null +++ b/.ci/asciidoc-converter/build_standard_debug.bat @@ -0,0 +1,3 @@ +mkdir ..\..\sdpi-documents +mkdir ..\..\sdpi-documents\sdpi-standard +gradlew.bat run --args="--input-file ../../asciidoc/sdpi-standard.adoc --output-folder ../../sdpi-documents/sdpi-standard --backend html" --debug diff --git a/.ci/asciidoc-converter/build_supplement.bat b/.ci/asciidoc-converter/build_supplement.bat new file mode 100644 index 00000000..8c7a97df --- /dev/null +++ b/.ci/asciidoc-converter/build_supplement.bat @@ -0,0 +1,3 @@ +mkdir ..\..\sdpi-documents +mkdir ..\..\sdpi-documents\sdpi-supplement +gradlew.bat run --args="--input-file ../../asciidoc/sdpi-supplement.adoc --output-folder ../../sdpi-documents/sdpi-supplement --backend html" diff --git a/CHANGELOG.md b/CHANGELOG.md index a6658d56..7c57b41a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,8 @@ Each section shall contain a list of action items of the following format: `> and <>. + +Note that NIST and the RTTMS tools are a key factor in the nomenclature aspect of the licensing discussion. + +|=== + +IEEE^®^ and IEEE 11073^®^ are registered trademarks of the The Institute of Electrical and Electronics Engineers, Inc. IEEE has granted permission to IHE and HL7 to use portions of 11073-10207, 11073-20701, 11073-20702, 11073-10700, 11073-10701 (the “Material”), subject to the following conditions: + +. IHE’s use of the Material shall be for the following purpose: (the “Purpose”): + +* IHE specification developers want to include the Implementation Conformance Specification (ICS) tables from each of these standards and add to the "Support" column the specifics of how and where the IHE specifications address the SDC capability. + +* Additionally, the IHE profile specifications may include summarization and references to specific content and in a few cases, inclusion of a graphic that would then point the reader back to standard for detailed review. For example, 11073-10207, Figure 2 "BICEPS component decomposition". + +* Finally, all three of these standards have integrated requirement designations. For example, 11073-20701, Section (10.1) "R0064: An SDC PARTICIPANT SHOULD utilize the highest TLS version." These requirements may also be referenced (at least by Rxxxx designator) to indicate when and how they are addressed in the IHE specification(s). IHE agrees to share with the 11073 working groups any iteration of its derivative work for the benefits of the 11073 community of users. + +. IHE understands and agrees that the following shall appear in each section where the material is used: + +* _Adapted and reprinted with permission from IEEE. Copyright IEEE Year. All rights reserved._* footnote:ieee_permission[Adapted and reprinted with permission from IEEE. Copyright IEEE Year. All rights reserved.] + +. IHE understands and agrees that the Material is the intellectual property of IEEE. Except as provided in this agreement no ownership rights to the Material shall be transferred to IHE. + +. Except as necessary to give effect to the Purpose, no other use of the Material including, but not limited to, reproduction or distribution of the IEEE Standards in any format is prohibited without prior written consent of IEEE. + +. The Material is provided “as is,” To the extent permitted by law, IEEE disclaims all representations and warranties to the Material. + +. IHE shall note that any comments or interpretations of the Material are its own and do not represent the views of IEEE, its members or affiliates. + +. IHE understands and agrees that this grant permission may not be transferred or assigned without the express written permission of IEEE. + diff --git a/asciidoc/document-declarations.adoc b/asciidoc/front-matter/document-declarations.adoc similarity index 91% rename from asciidoc/document-declarations.adoc rename to asciidoc/front-matter/document-declarations.adoc index 07d94e39..e491953e 100644 --- a/asciidoc/document-declarations.adoc +++ b/asciidoc/front-matter/document-declarations.adoc @@ -9,23 +9,21 @@ NOTES: //// -[#supplement_clause_forward_declarations,sdpi_offset=clear] +[#standard_clause_forward_declarations,sdpi_offset=clear] == Standard Forward Declarations [%noheader] [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: - -*Standalone SDPi:* _REWORK this section to make it a permanent Forward Declarations, perhaps refactoring it into something that is not labeled "Forward Declarations"!_ +a| *{standard_note}*: The following table is included in this version of the standard to capture *_"forward" declarations of acronyms and labels_* that are used in the text but are not intended to be part of the General Introduction Appendix D Glossary. "Forward" means that they are used BEFORE the document section in which they are formally defined. Since AsciiDoc is a one-pass processor, forward declarations are required. There was no clear way of defining these replacement definitions in a way that is "under the hood" and not visible to the reader. -The following table was thus created but may be moved or otherwise implemented in subsequent supplement versions. +The following table was thus created but may be moved or otherwise implemented in subsequent standard versions. Suggestions appreciated! diff --git a/asciidoc/front-matter/forward.adoc b/asciidoc/front-matter/forward.adoc new file mode 100644 index 00000000..b13d7600 --- /dev/null +++ b/asciidoc/front-matter/forward.adoc @@ -0,0 +1,36 @@ + +[#standard_clause_foreword,sdpi_offset=clear] += Foreword + +== HL7-IHE Gemini Device Interoperability Program + +Recognizing the decades-long close collaboration between between Health Level Seven International (HL7) and Integrating the Healthcare Enterprise (IHE), and in order to better facilitate coordinated development, the Gemini Program was created as a home for joint projects. +This Gemini standard is one such joint development project between the HL7 and IHE Devices working groups focused on acute care, plug-and-trust medical device interoperability. +Its development and publication adheres to the consensus standards processes of both HL7, an ANSI accredited standards development organization, and IHE. +The title of this document, *_Technical Framework Profile Standard_*, reflects its unique status as a Gemini specification, utilizing the IHE Technical Framework organization and elements (e.g., integration profiles, actors, transactions, content modules), but processed as an HL7 specification that will be published as a "standalone" standard and will persist even when its status transitions to normative standard (HL7) or Final Text (IHE). + +To facilitate integration with the companion IHE Devices Technical Framework (final text) specification, a companion to this standard is created for each edition: "IHE Devices Technical Framework _Supplement_ -- Service-oriented Device Point-of-care Interoperability (SDPi)", which will be organized and adhere to IHE style guidelines for supplement documents, but it will be in major section outline only, with each section including a note indicating where the content is located in the published *Gemini Technical Framework Profile _Standard_* (this document). +Given its alignment with the companion IHE specification, some section numbers are skipped in this document to facilitate its intended integration into the above-mentioned "standard". +Skipped section numbers are already present in the Devices Technical Framework and will not require changes due to the incorporation of the supplement once it transitions to normative standard / final text status. + +Additionally, some content that may otherwise be only referenced by a "supplement" document and defined elsewhere in the existing technical framework, will be incorporated in this specification to ensure that it is internally cohesive and does not force the reader to unnecessarily consult other documents. + +Publication as a *Standard for Trial Use* (HL7 STU) or *Trial Implementation* (IHE TI) reflects the continuous cycle of development, balloting and publication of the specification, to address addition of new capabilities as well as identified safety, effectiveness and security issues and enhancements. +Product developers are encouraged to use the standard, recognizing the potential impact of this continuous development cycle and its status as a _"trial use"_ standard. + + +This supplement is published on {ihe_standard_sdpi_publication_month} for Trial Implementation and may be available for testing at subsequent IHE or HL7 testing events, such as an IHE Connectathon. +The standard may be amended based on the results of testing. +Following successful testing and implementation maturity, it will transition to a normative standard, and the companion IHE supplement will be incorporated into the Devices Technical Framework. +Comments are invited and can be submitted at https://www.ihe.net/DEV_Public_Comments/[Devices Public Comments] or by submitting a https://github.com/IHE/DEV.SDPi/issues/new/choose[GitHub Issue]. + +General information about IHE can be found at http://www.ihe.net/[IHE.net], and about HL7 can be found at https://www.hl7.org/index.cfm[HL7.org]. + +General information about the HL7 Devices Working Group can be found at https://www.hl7.org/Special/committees/healthcaredevices/index.cfm[HL7.org/healthcaredevices], and the IHE Devices domain can be found at https://www.ihe.net/ihe_domains/[IHE Domains]. + +Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at https://www.ihe.net/resources/profiles/[Profiles] and https://www.ihe.net/about_ihe/ihe_process/[IHE Processes]. + +The current version of the IHE Devices Technical Framework can be found at https://profiles.ihe.net/DEV/[DEV Technical Framework]. + +include::standard-issues.adoc[] + diff --git a/asciidoc/front-matter/glossary.adoc b/asciidoc/front-matter/glossary.adoc new file mode 100644 index 00000000..beb335dd --- /dev/null +++ b/asciidoc/front-matter/glossary.adoc @@ -0,0 +1,509 @@ + +[#clause_glossary,sdpi_offset=clear] +=== General Terms + + +[%noheader] +[%autowidth] +[cols="1"] +|=== +|Add the following *_new or updated_* glossary terms to the IHE Technical Frameworks General Introduction https://profiles.ihe.net/GeneralIntro/ch-D.html[Appendix D]. +|=== + +[%autowidth] +[cols="^2,3,^1,^1,^1,^1"] +|=== +|New Glossary Term |Definition |Synonyms |Acronyms / Abbreviation |References |Type + +| [[term_abrupt_time_adjustment,abrupt time adjustment]] Abrupt time adjustment +| A large change (typically more than 5 minutes) to a <>'s <> to reconcile differences between the time reported by a <> and a <>, within the statistical uncertainty of the synchronization algorithm, as quickly as possible. Abrupt time-adjustments are also known as step-changes and <>s, particularly when using <> to synchronize a <>. +| <> +| +| <> +| Time + +| [[term_american_national_standards_institute,American National Standards Institute (ANSI)]] American National Standards Institute +| The primary United States <> recognition and facilitation organization. +| +| [[acronym_ansi,ANSI]] ANSI +| https://ansi.org/[ANSI.org] +| Organization + +|[[term_basic_ice_protocol_specification,Basic ICE Protocol Specification (BICEPS)]] Basic ICE Protocol Specification +| General reference to the abstract, implementation technology independent SDC components defined in the IEEE 11073-10207 standard. +| +| [[acronym_biceps,BICEPS]] BICEPS +| <> +| SDC + +| [[term_central_station,Central Station]] Central Station +| A system that supports a multi-patient workplace with capabilities similar to a Cockpit. +| +| +| See extended description and discussion in <> +| + +| [[term_classic_dim,Classic DIM]] Classic Domain Information Model (DIM) +| The foundational domain information model (DIM) that is recognized and implemented in all IEEE 11073 standards and profiles, for both <> and <> devices. +| +| [[acronym_dim,DIM]] DIM +| <> +| SDC + +| [[term_clinical_function,Clinical Function]] Clinical Function +| Function or feature intended to be used for one or more specific medical purposes including but not limited to examination, monitoring, or modification of the structure or function of an individual's body; prediction, prevention, diagnosis, prognosis, treatment, or alleviation of a medical condition. +| +| [[acronym_cf,CF]] CF +| <> +| SDC + +| [[term_clock_discipline_algorithm,clock-discipline algorithm]] Clock-discipline algorithm +| The algorithm employed by a <> client to minimize the error between the <> and the <>. It may include startup calibration steps, smooth (e.g., slewing) and, rarely, abrupt (e.g., non-slewing) corrections. +| +| +| <> +| Time + +| [[term_coded_attribute, Coded Attribute]] Coded Attribute +| A BICEPS Participant Model extension that allows for a <> to provide attributes from the first partition of the IEEE 11073-10101 nomenclature. Specified in <>. +| +| +| See https://www.nist.gov/conformity-assessment[NIST CA resources page] +| SDC + +| [[term_conformity_assessment, Conformity Assessment]] Conformity Assessment +| The activity of verifying that a standard or technical specification was applied in the design, manufacturing, installation, maintenance or repair of a device or system. "Product CA" is often mentioned to clarify its use in the context of this document. +| +|[[acronym_ca,CA]] CA +| +| SES + +| [[term_device_to_device, Device-to-Device]] Device-to-Device +| Direct communication between two devices across a communications infrastructure. It is used here to differentiate between "device gateway-to-gateway" or intermediary-based communication. +| peer-to-peer, machine to machine +| [[acronym_d2d,D2D]] D2D +| https://en.wikipedia.org/wiki/Device-to-device[Device-to-device wikipedia article with references] +| SDC + +| [[term_discovery_scope, Discovery Scope]] Discovery Scope +| A set of zero to many identifiers that allows for organizing <>s into logical groups. +| +| +| +| SDC + +| [[term_electronic_health_record, Electronic Health Record]] Electronic Health Record +| An electronic record derived from a computer system that maintains a longitudinal view of a patient’s history. It contains comprehensive information on a patient’s health used primarily for delivering patient care in a clinical setting. +| +| [[acronym_ehr,EHR]] EHR +| https://profiles.ihe.net/GeneralIntro/ch-D.html[IHE General Introduction Appendix D Glossary] +| IHE + +| [[term_epoch,epoch]] Epoch +| A distinct period of time characterized by a consistent temporal properties described by a <>. +| +| +| +| Time + + +| [[term_fast_healthcare_interoperability_resources,Fast Healthcare Interoperability Resources (FHIR)]] Fast Healthcare Interoperability Resources +| An <> standard for health care data exchange, built on RESTful technology that utilizes _resources_ to enable rapid creation of interoperable healthcare applications. +| +| [[acronym_fhir,FHIR]] FHIR +| https://hl7.org/fhir/[HL7 FHIR home] +| Standard + +| [[term_health_level_seven_international,Health Level Seven International (HL7)]] Health Level Seven International +| Organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. +| +| [[acronym_hl7,HL7]] HL7 +| https://www.hl7.org/about/index.cfm?ref=nav[About -- HL7] +| Organization + +| [[term_historic_localized_text, Historic Localized Text]] Historic Localized Text +| A pm:LocalizedText element that was referenced from within a pm:Mdib or msg:AbstractReport in an MDIB Sequence of Changes +| +| +| +| SDC + +| [[term_history_service, History Service]] History Service +| A service to access historical <> data by means of an initial <> and subsequent change reports. The History Service replaces the ARCHIVE SERVICE specified in <> and is used to implement <>. +| +| +| +| SDC + +| [[term_implementation_conformance_statement,Implementation Conformance Statement (ICS)]] Implementation Conformance Statement +| A clause in many standards that specifies how conformance claims to that standard should be formalized, including identification of any deviations, extensions and option selection. +| +| [[acronym_ics,ICS]] ICS +| +| + +| [[term_institute_of_electrical_and_electronics_engineers,Institute of Electrical and Electronic Engineers (IEEE)]] Institute of Electrical and Electronic Engineers +| Organization dedicated to advancing innovation and technological excellence for the benefit of humanity, and is the world's largest technical professional society +| +| [[acronym_ieee,IEEE]] IEEE +| https://www.ieee.org/about/ieee-history.html?utm_source=linkslist_text&utm_medium=lp-about&utm_campaign=history[About -- History of IEEE] +| Organization + +| [[term_integratec_clinical_environment,Integrated Clinical Environment (ICE)]] Integrated Clinical Environment +| Environment that combines interoperable heterogeneous POINT-OF-CARE (PoC) MEDICAL DEVICEs and other equipment integrated to create a medical device system for the care of a single high acuity patient. +| +| [[acronym_ice,ICE]] ICE +| <>; +<> +| SDC + +| [[term_international_medical_device_regulators_forum,International Medical Device Regulators Forum (IMDRF)]] International Medical Device Regulators Forum +| A voluntary group of medical device regulators from around the world who have come together to build on the strong foundational work of the Global Harmonization Task Force on Medical Devices (GHTF) and aim to accelerate international medical device regulatory harmonization and convergence. +| +| [[acronym_imdrf,IMDRF]] IMDRF +| https://www.imdrf.org/[IMDRF.org] +| Organization + +| [[term_international_standards_organization,International Standards Organization (ISO)]] International Standards Organization +| A globally recognized one-country-one-vote <> that is composed of 100's of technical committees and other groups. +| +| [[acronym_iso,ISO]] ISO +| https://www.iso.org/home.html[www.ISO.org] +| Organization + +| [[term_joint_working_group_7,ISO/IEC Joint Working Group 7 (JWG7)]] ISO/IEC Joint Working Group 7 +| A joint standardization group between ISO/TC 215 and IEC/SC 62A focused on the <> health software and health IT systems, including those incorporating medical devices. +| +| [[acronym_jwg7,JWG7]] JWG7 +| https://www.iso.org/committee/54960.html[ISO/TC 215 Health Informatics], https://www.iec.ch/dyn/www/f?p=103:29:::::FSP_ORG_ID:1359[IEC SC/62A] +| Organization + +| Local Area Network +| A computer network that interconnects computers within a limited area such as a hospital, ICU bed, laboratory, or office building. By contrast, a wide area network (WAN) not only covers a larger geographic distance, but also generally involves leased telecommunication circuits. +| +| [[acronym_lan,LAN]] LAN +| See https://en.wikipedia.org/wiki/Local_area_network["Local area network" article] for more information and references. +| + +| [[term_manufacturer, Manufacturer]] Manufacturer +| Natural or legal person with responsibility for the design, manufacture, packaging, or labeling of medical electrical equipment, assembling a medical electrical system, or adapting medical electrical equipment or a medical electrical system, regardless of whether these operations are performed by that person or on that person's behalf. +| +| +| +| Organization + +| [[term_medical_data_information_base,Medical Data Information Base (MDIB)]] Medical Data Information Base +| Structured collection of any data objects that are provided by a <> or <>, including both descriptive and state information. +| +| [[acronym_mdib,MDIB]] MDIB +| <> +| SDC + +| [[term_mdib_configuration, MDIB Configuration]] MDIB Configuration +| <> that describes the state of a <> at a specific MDIB version. +| +| +| +| SDC + +| [[term_mdib_sequence_of_changes, MDIB Sequence of Changes]] MDIB Sequence of Changes +| <> changes within a particular pm:Mdib/@SequenceId and pm:Mdib/@InstanceId (if present) that is requested from a <>. +| +| +| +| SDC + +| [[term_medical_device,Medical Device (MD)]] Medical Device +| A device that is used to diagnose, monitor and treat disease. Formal definitions may vary per legal jurisdictions; however, the international, harmonized (and *_very lengthy_*) definition is available from the <> web site. +| +| [[acronym_medical_device,MD]] MD +| <> +| + +| [[term_medical_device_communication,Medical Device Communication (MDC)]] Medical Device Communication +| A general term that refers to all aspects of standards-based exchanges between medical (and health) devices, including <> and <>; in some contexts, for example <>, it refers to the IEEE 11073-10101 Nomenclature or "coding system". +| +| [[acronym_mdc,MDC]] MDC +| <> +| + +| [[term_medical_device_interoperability,Medical Device Interoperability (MDI)]] Medical Device Interoperability +| The application of informatics technology standards to achieve seamless and dynamic connection of <>'s. +| +| [[acronym_mdi,MDI]] MDI +| https://www.fda.gov/medical-devices/digital-health-center-excellence/medical-device-interoperability[See also U.S. FDA MDI Definition] +| + +| [[term_medical_device_lan,Medical Device LAN (MD LAN)]] Medical Device LAN +| A local area network that integrates <>s often around a single bedside <> or care area (e.g., operating room, ICU or Emergency Department). +| [[acronym_sdc_lan,SDC LAN]] SDC LAN +| [[acronym_md_lan,MD LAN]] MD LAN +| +| + +| [[term_medical_device_system,Medical Device System (MDS)]] Medical Device System +| A core object type in the IEEE 11073 device communication standards. It represents the top-level containment of the hierarchy of information objects contained in a device. +| +| [[acronym_mds,MDS]] MDS +| <>, <> +| + +| [[term_model_based_systems_engineering,Model-Based Systems Engineering (MBSE)]] Model-Based Systems Engineering +| An approach to systems engineering where a single, highly integrated, executable model is created (often using OMG System's Modeling Language (e.g., <>), to capture all elements, from requirements to system components to Verification & Validation test cases. +| +| [[acronym_mbse,MBSE]] MBSE +| See also <>, <> and <> +| SES + +| [[term_model_centric,Model-Centric (MC)]] Model-Centric +| An approach to systems specification that captures all information in a single model (e.g., using <>), and from which "views" are generated to support all specification stakeholders and usages. +elements, from requirements to system components to Verification & Validation test cases. Note: The _model-centric_ approach replaces the traditional _document-centric_ approach. +| [[acronym_ri_mc_rr,RI+MC+RR]] RI+MC+RR +| [[acronym_mc,MC]] MC +| See also <> and <> +| SES + +| [[term_network_time_protocol,Network Time Protocol (NTP)]] Network Time Protocol +| A networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. +| +| [[acronym_ntp,NTP]] NTP +| https://en.wikipedia.org/wiki/Network_Time_Protocol[NTP wikipedia article], <> +| + +| [[term_non_slewing_time_adjustment,non-slewing time adjustment]] Non-slewing time adjustment +| The <> to a system clock's <> described by <>. +| <> +| +| <> +| Time + +| [[term_object_management_group, Object Management Group (OMG)]] Object Management Group +| An international, membership-driven, not-for-profit consortium <>. +| +| [[acronym_omg,OMG]] OMG +| https://www.omg.org/[OMG.org] +| Organization + +| [[term_participant_key_purposes,Participant Key Purposes (PKP)]] Participant Key Purposes +| These generally refer to the IEEE 11073-1070x standards that provide a consensus set of risk control measures aligned with the four core <> functions: <>, reporting, alerting and external control. +| +| [[acronym_pkp,PKP]] PKP +| <> +| SDC + +// FOR THE FOLLOWING ROW ADD TO THE REFERENCES COLUMN: +// #TODO: ADD 11073 PHD REFERENCES?# +| [[term_personal_health_device,Personal Health Device (PHD)]] Personal Health Device +| A healthcare device that is used by individuals for their own personal health purposes. +| +| [[acronym_phd,PHD]] PHD +| +| + +| [[term_plug_and_trust,Plug-and-Trust (PnT)]] Plug-and-Trust +| The integration of an SES framework and MDI plug-and-play technology to enable the dynamic establishment of trust between participant systems at the point of connection to a <> network. +| [[acronym_ses_mdi,SES+MDI]] SES+MDI +| [[acronym_pnt,PnT]] PnT +| +| + +| [[term_point_of_care,Point of Care (PoC)]] Point of Care +| Typically where the patient is, such as their clinical bedside; although, it may also be used to include mobile patients (e.g., that are connected to telemetry monitoring). +| +| [[acronym_poc,PoC]] PoC +| +| + +| [[term_poc_cockpit,PoC Cockpit]] Point of Care Cockpit +| A system that supports information viewing and control of multiple devices and systems associated with a single patient <>. +| [[term_cockpit,Cockpit]] Cockpit +| +| +| + +| [[term_poc_dashboard,PoC Dashboard]] Point of Care Dashboard +| A system that displays information from one or more <> systems associated with a single patient. Similar to a <> but without device-external control capabilities. May include both metric and alert information. +| Dashboard +| +| +| + +| [[term_point_of_care_device,Point of Care Device (PoCD)]] Point of Care Device +| A healthcare device that is used at a <>, typically at a patient’s clinical bedside. May include patient-connected mobile devices, such as telemetry monitors. +| +| [[acronym_pocd,PoCD]] PoCD +| +| + +| [[term_q_name, QName]] QName +| XML Schema QName. In this specification, QNames are encoded as `{}`. +| +| +| +| + +| [[term_reference_clock,reference clock]] Reference clock +| The source of time obtained from a <> and shared between <>s. +| +| +| +| Time + +| [[term_regulatory_ready,Regulatory Ready (RR)]] Regulatory Ready +| For regulated medical device technology, integrating <> and <> content such that conformity assessment test reports may be directly included as supporting evidence in pre-market submissions to regulatory agencies. It is part of the Requirements Interoperability + Model Centric + Regulatory Ready (<>) focus of the IHE Devices Technical Framework. +| <> +| [[acronym_rr,RR]] RR +| See also <> and <> +| + +| [[term_removable_subsystem,Removable Subsystem]] Removable Subsystem +| A subsystem of a <> that can be attached to or removed from the <> and that is represented in the <>. +| +| +| See also <> +| + +| [[term_requirements_interoperability,Requirements Interoperability (RI)]] Requirements Interoperability +| The ability to specify the requirements of one specification in such a way that they can be connected with capabilities of other specifications. It is part of the Requirements Interoperability + Model Centric + Regulatory Ready (RI+MC+RR) focus of the IHE Devices Technical Framework. +| RI+MC+RR +| [[acronym_ri,RI]] RI +| See also <> and <> +| + +| [[term_safe_effective_secure,Safe Effective & Secure (SES)]] Safe, Effective & Secure +| General name given to the requirements, general and specific, derived by the application of medical device and health software quality standards. +| +| [[acronym_ses,SES]] SES +| <>; <> +| + +| [[term_service_oriented_device_connectivity,Service-oriented Device Connectivity (SDC)]] Service-oriented Device Connectivity +| Application of service-oriented architecture to support healthcare device interoperability. +| +| [[acronym_sdc,SDC]] SDC +| <> +| 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 four IHE specifications that profile the <> standards for device-to-device plug-and-play interoperability. +| +| [[acronym_sdpi,SDPi]] SDPi +| +| Profile + +| [[term_service_oriented_architecture,Service-oriented Architecture (SOA)]] Service-oriented Architecture +| An architectural style that focuses on discrete services, where provider components supply services (discrete units of functionality) to consumer components across a communications network infrastructure. +| +| [[acronym_soa,SOA]] SOA +| +| SDC + +| [[term_service_oriented_medical_device_system,Service-oriented Medical Device System (SOMDS)]] Service-oriented Medical Device System +| A point-of-care system of products that +implements a service-oriented <> architecture composed of service providers and service consumers. +| +| [[acronym_somds,SOMDS]] SOMDS +| <> +| SDC + +| [[term_slewing_adjustments,slewing time adjustments]] Slewing time adjustments +| Adjustments, typically small, made to a <>'s frequency described by <>. Generally so the time reported by the <> matches that of a <> at some point in the not too distant future, within the statistical uncertainty of the synchronization algorithm. +| <> +| +| <> +| Time + +| [[term_smart_alarm_system,Smart Alarm System (SAS)]] Smart Alarm System +| A system that provides consolidated alarm and alert events (actionable alerts), and advisories (e.g., patient deterioration alerts). +| +| [[acronym_sas,SAS]] SAS +| +| + +| [[term_smooth_time_adjustments,smooth time adjustments]] Smooth time adjustments +| A gradual adjustment within a <>, characterised by a continuous and monotonically increasing progression of timestamps without abrupt jumps or disruptions to the passage of time. Generally so that the time reported by a system clock matches that of a <> at some point in the future, within the statistical uncertainty of the synchronization algorithm. Typically involves running the <> faster or slower for some period. +| <> +| +| <> +| Time + +| [[term_software_as_a_medical_device,Software as a Medical Device (SaMD)]] Software as a Medical Device +| Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. +| +| [[acronym_samd,SaMD]] SaMD +| https://www.fda.gov/medical-devices/cdrh-international-programs/international-medical-device-regulators-forum-imdrf[Source: <>] +| + +| [[term_somds_provider_uid, SOMDS Provider UID]] SOMDS Provider UID +| A globally unique identifier <> for a <> that is stable across re-initializations (i.e., resets / reboots). +| [[acronym_uid,UID]] UID +| +| +| SDC + +| [[term_standards_development_organization,Standards Development Organization (SDO)]] Standards Development Organization +| An organization that has a core objective of developing consensus-based standards, typically recognized or accredited by national and international organizations (e.g., <> or <>) +| +| [[acronym_sdo,SDO]] SDO +| https://en.wikipedia.org/wiki/Standards_organization["Standards organization" wikipedia article] +| Organization + +| [[term_system_clock,system clock]] System clock +| A source of <>s used in a <>s system function contributions (<>). +| +| +| +| Time + +| [[term_system_function_contribution,System Function Contribution (SFC)]] System Function Contribution +| Function of a <> that contributes to a <> provided by a <>. +| +| [[acronym_sfc,SFC]] SFC +| Adapted from <>. +| SDC + +| [[term_time_reference_frame,time-reference frame]] Time-reference frame +| A device-specific context for measuring and assigning timestamps to events. The reference frame is defined by its rate of passage of time and alignment to some external temporal standard (e.g., provided by a <>). The reference frame's time-rate may vary with time (e.g., a <> to synchronize with an external temporal standard). Abrupt changes to the time-reference frame alignment to an external standard (e.g., <>), create distinct time-reference frames with different temporal characteristics. +| +| +| +| Time + +| [[term_timestamp,timestamp]] Timestamp +| A point in time obtained from a <>. Timestamps are obtained within the context of a <>. +| +| +| +| Time + +| [[term_timestamp_version,timestamp version]] Timestamp version +| A unique identifier, within the scope of a MDIB sequence, of a <> epoch. +| +| +| +| Time + +| [[term_time_synchronization_service,Time Synchronization Service (TS Service)]] Time Synchronization Service +| A general network service capability that enables systems to obtain and synchronize to a common and accurate time source. For example, <>. +| +| [[acronym_ts_service,TS Service]] TS Service +| +| + +| [[term_transport_address, Transport Address]] Transport Address +| A physical endpoint address that can be used to communicate with a <> or <> . +| XAddr +| +| +| + +| [[term_medical_device_system,Virtual Medical Device (VMD)]] Virtual Medical Device +| A core object type in the IEEE 11073 device communication standards. It represents the second-level containment of the hierarchy of information objects contained in a device. +| +| [[acronym_vmd,VMD]] VMD +| <>, <> +| + +|=== + + diff --git a/asciidoc/std-oid-definitions.adoc b/asciidoc/front-matter/oid-definitions.adoc similarity index 100% rename from asciidoc/std-oid-definitions.adoc rename to asciidoc/front-matter/oid-definitions.adoc diff --git a/asciidoc/front-matter/overview.adoc b/asciidoc/front-matter/overview.adoc new file mode 100644 index 00000000..f01fac90 --- /dev/null +++ b/asciidoc/front-matter/overview.adoc @@ -0,0 +1,182 @@ + + + +[#clause_overview,sdpi_offset=clear] += Overview + +[#clause_sdpi_standard_scope] +== Scope + + +[#clause_sdpi_standard_purpose] +== Purpose + +NOTE: #content from current TF-1:2.3.1.1 and similar# + + +[#clause_sdpi_standard_copyright_licenses_trademarks] +== Copyright Licenses & Trademarks + +NOTE: #Copyright and Trademark info# + +include::copyrights.adoc[] + +// SDPi Trademark + +=== Trademark +IHE^®^ and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. +Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-10.html[Section 10 - Trademark] for information on their use. + +[#clause_sdpi_xml_namespaces] +== XML Namespaces + +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 specification. +The choice of any namespace prefix is arbitrary and not semantically significant. + +.Prefixes and XML namespaces used in this specification. +[#table_xml_namespaces,cols="1,5,2",width=100%,] +|=== +|Prefix |XML Namespace |Specification + +|sdpi +|urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1 +|This specification, used by <> extensions. + +|dp +|urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2 +|This specification, used by the <> actor. + +|dpws +|http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01 +|<> + +|hs +|urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.3.1 +|This specification, used by service specification of the <>. + +|hm +|urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.3.2 +|This specification, used by model specification of the <>. + +|wsa +|http://www.w3.org/2005/08/addressing +|<> + +|wsd +|http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01 +|<> + +|wse +|http://schemas.xmlsoap.org/ws/2004/08/eventing +|<> + +|wsm +|http://schemas.xmlsoap.org/ws/2004/09/mex +|<> + +|=== + + +// Forward declarations of common labels & acronyms & variables +include::document-declarations.adoc[] + +// Define oids for referenced standards +include::oid-definitions.adoc[] + +[#standard_clause_sdpi_standard_overview] +== SDPi Standard Overview + +[#standard_clause_sdpi_organization] +=== SDPi Organization + +This IHE Devices Technical Framework standard 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 standard includes updates to all three IHE DEV TF volumes, including: + +*TF-1 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 + +*TF-2 Transactions* + +* Extensive new set of transactions based on IEEE 11073 Service-oriented Device Connectivity (SDC) medical device interoperability standards. +* Related appendices, for example the specialized use of web services messaging for device communication and gateways to other protocols or profiles + +*TF-3 Content Modules* + +* New content covering the application of IEEE 11073 SDC semantic standards to device content modules, with a primary focus on specifications related to the IEEE 11073-10207 BICEPS standard. + +NOTE: As explained in the https://profiles.ihe.net/GeneralIntro/ch-7.html#7.5[IHE Technical Framework Document Conventions], the acronym TF stands for Technical Framework, whereas the number immediately behind the hyphen in the "TF-X" notation stands for the volume number within a Technical Framework. + +[#standard_clause_mapping_clinical_scenarios_to_profile_requirements] +=== Use Cases: Mapping Clinical Scenarios to Profile Requirements +IHE technical framework integration profile specifications include use case sections to ensure that the technical solutions are rooted in real-world application requirements. +These sections typically include a basic description of use case scenarios, identify the key systems that exchange information, application-level detail of the information exchanged, and perhaps even some sequence diagrams. +This information may also be used to drive the test cases that are used for conformity assessment, ensuring that the resulting specification implementation meets the intended needs. + +This standard includes this same organization; however, it also defines a set of general, non-profile-specific clinical use cases that provide requirements, which may be mapped to multiple SDPi integration profiles. +Section <> provides a collection of these high-level clinical use cases. + +FOR READERS OF THIS STANDARD, 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 requirements have been mapped. +Reviewing the use case specifications in this order will provide the needed context to understand what is presented in each profile. + +[#standard_clause_joint_ihe_hl7_gemini_ses_mdi_project_development] +=== Joint IHE-HL7 Gemini SES+MDI Project Development +This standard is the result of a joint https://confluence.hl7.org/x/Xzf9Aw[IHE-HL7 Gemini Device Interoperability program] which began early 2020. +Extensive notes and discussion materials are provided on the project's HL7 Confluence site, including a https://confluence.hl7.org/pages/viewpage.action?pageId=113674346#LibrarywithEVERYTHINGyoueverwantedtoknow...-GeneralUpdate&BriefingPresentations[Library with extensive presentations and other materials]. +This Library also includes *_briefings (slides and recordings) to provide background for those reviewing the specification_*. + +The joint IHE-HL7 devices team leveraged tools from both organizations, as well as participated jointly throughout the project's multi-year efforts. + +The methods currently employed are provided in the wiki article: https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#program-coordination--co-working-spaces[Program Coordination & Co-Working Spaces]. + +[#standard_clause_support_for_ri_mc_rr_using_asciidoc] +=== Support for RI+MC+RR using AsciiDoc +In addition to the standard's technical specification content, a development approach has been advanced that represents added value to adopters and implementers over the traditional document oriented approach. +These are referred to as: + +[none] +. *_Requirements Interoperability + Model Centric + Regulatory Ready_* + +Or *RI+MC+RR* for short. + +These three objectives may be summarized as follows: + +[none] +* *Requirements Interoperability (RI)* +[none] +** 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 +* *Regulatory Ready (RR)* +[none] +** Enable CA test reports that are genuinely _"regulatory submission ready"_ (e.g., inclusion in a U.S. FDA 510(k) submission package) + +The SDPi {gemini_standard_sdpi_revision} version of the standard 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 standard represents a humble start in that direction. +Subsequent standard 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]. +See also related discussions on the Gemini Project's https://confluence.hl7.org/x/XhPUB[Pathway to an Ecosystem of Plug-and-Trust Products]. + + +[#clause_sdpi_actors_summary] +=== SDPi Actors Summary + +include::summary-actors.adoc[] + +[#clause_sdpi_transactions_summary] +=== SDPi Transactions Summary + +include::summary-transactions.adoc[] + diff --git a/asciidoc/front-matter/references.adoc b/asciidoc/front-matter/references.adoc new file mode 100644 index 00000000..2c3f3fa9 --- /dev/null +++ b/asciidoc/front-matter/references.adoc @@ -0,0 +1,9 @@ + + +[#clause_references,sdpi_offset=clear] += References + +NOTE: #This new section integrates the content formerly in TF-1B)# + +include::tf1-ch-b-ref-standards-conformance.adoc[] + diff --git a/asciidoc/front-matter/standard-issues.adoc b/asciidoc/front-matter/standard-issues.adoc new file mode 100644 index 00000000..347836b7 --- /dev/null +++ b/asciidoc/front-matter/standard-issues.adoc @@ -0,0 +1,49 @@ + +[#sdpi_release_issue_management] +== SDPi Release & Issue Management + +[sdpi_offset=clear] +=== Overview + +All SDPi standard issues are tracked in the https://github.com/IHE/DEV.SDPi/issues[IHE Github DEV.SDPi repository Issues section]. +Filter the issues on their "state" to see them. + + +* To see the full list of OPEN issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen +* To see the full list of CLOSED issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed + +For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this standard, see the https://github.com/IHE/DEV.SDPi/wiki[_IHE SDPi wiki_]. + +[sdpi_offset=clear] +[#sdpi_release_issue_tracking] +=== Release - Issue Tracking + +All releases of the SDPi standard include a list of issues that were closed and integrated into that version of the specification. +To review the issues are associated with a specific release of the standard: +. Go to https://github.com/IHE/DEV.SDPi/releases +. Select the desired release from the list +. Select "Please click here for a detailed changelog" for that release + +All of the identified changes include a link back to the associated SDPi Issue that enables review of all associated updates to the specification, as well as all the individuals, discussions and review processes that were involved. + +Since this is a joint HL7 - IHE Gemini publication, HL7 Jira issues that result from an HL7 ANSI-accredited ballot cycle, are linked reciprocally with a GitHub issue. +In this way, namely bidirectional linking from Jira ticket and GitHub issue, round-trip traceability is achieved for resolution of ballot comments and the SDPi release in which the resolutions were implemented. + +[sdpi_offset=clear] +=== Open Issues + +The issues listed in this section or in https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen are open, and hence not yet ready for inclusion in this release and not subject to comment or review. + +//==== Open Issues +// NOTE: The following line must be kept exactly as worded in order for the processor to replace it with the list + +// open issues are inserted here + +[sdpi_offset=clear] +=== Closed Issues + +The issues listed in this section or in https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed are closed. + +// NOTE: The following line must be kept exactly as worded in order for the processor to replace it with the list + +// closed issues are inserted here + diff --git a/asciidoc/front-matter/summary-actors.adoc b/asciidoc/front-matter/summary-actors.adoc new file mode 100644 index 00000000..554feb11 --- /dev/null +++ b/asciidoc/front-matter/summary-actors.adoc @@ -0,0 +1,135 @@ + +// [appendix#vol0_appendix_a_actors,sdpi_offset=A] +// === Actors + +[%noheader] +[%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]. +|=== + +//// +#TODO: ADD "summary_" TO THESE DEFINITIONS OR KEEP THEM AS IS; IF WE ADDED summary_ THEN THE MAIN REFERENCE WOULD BE TO THE PROFILE IN WHICH THEY ARE USED BUT AN ACTOR MAY BE USED IN MULTIPLE PROFILES ...# +//// + +[cols="1,2"] +|=== +|New (or modified) Actor Name |Definition + +|[[actor_biceps_content_consumer,BICEPS Content Consumer]] BICEPS Content Consumer + +|Processes BICEPS-conformant content. + +|[[actor_biceps_content_creator,BICEPS Content Creator]] BICEPS Content Creator + +|Provides BICEPS-conformant content. + +|[[actor_somds_acm_gateway,SOMDS ACM Gateway]] SOMDS ACM Gateway + +|Exchanges medical alert information with an IHE ACM-based environment + +|[[actor_somds_connector,SOMDS Connector]] SOMDS Connector + +|Enables seamless interaction with systems and software applications that are outside the scope of a SOMDS network. + +|[[actor_somds_consumer,SOMDS Consumer]] SOMDS Consumer + +|Discovers and utilizes service(s) exposed by a <>. + +|[[actor_somds_dec_gateway,SOMDS DEC Gateway]] SOMDS DEC Gateway + +|Exchanges information between <> and IHE DEC-based environments. + +|[[actor_somds_discovery_proxy,Discovery Proxy]] Discovery Proxy + +|Accepts and makes available <> endpoint metadata in a <>. + +|[[actor_somds_fhir_gateway,SOMDS FHIR Gateway]] SOMDS FHIR Gateway + +|Exchanges information between SOMDS and HL7 FHIR-based environments. + +|[[actor_somds_fhir_medical_data_gateway,SOMDS FHIR Medical Data Gateway]] SOMDS FHIR Medical Data Gateway + +|Exchanges medical data between SOMDS and HL7 FHIR-based environments. + +|[[actor_somds_medical_alert_consumer,SOMDS Medical Alert Consumer]] SOMDS Medical Alert Consumer + +|Receives medical alert information from a <>. + +|[[actor_somds_medical_alert_provider,SOMDS Medical Alert Provider]] SOMDS Medical Alert Provider + +|Makes medical alert information and service(s) available to <>s. + +|[[actor_somds_medical_control_consumer,SOMDS Medical Control Consumer]] SOMDS Medical Control Consumer + +|Discovers and invokes device-external control services supported by a +<>. + +|[[actor_somds_medical_control_provider,SOMDS Medical Control Provider]] SOMDS Medical Control Provider + +|Supports a set of device-external control services that may be discovered and invoked by a <>. + +|[[actor_somds_medical_data_consumer,SOMDS Medical Data Consumer]] SOMDS Medical Data Consumer + +|A <> grouped actor that receives medical data from a <>. + +|[[actor_somds_medical_data_provider,SOMDS Medical Data Provider]] SOMDS Medical Data Provider + +|Sends medical data to a <>. + +|[[actor_somds_participant,SOMDS Participant]] SOMDS Participant + +|Provides basic, common connectivity capabilities that are shared by all actors that are part of a SOMDS network. + +|[[actor_somds_provider,SOMDS Provider]] SOMDS Provider + +|Makes service(s) available to <>s. + + +|[[actor_somds_sensor_gateway,SOMDS Sensor Gateway]] SOMDS Sensor Gateway + +|Supports integration of sensors external to a SOMDS network. + +|[[actor_somds_smart_app_platform,SOMDS Smart App Platform]] SOMDS Smart App Platform + +|Supports connection of software applications to a SOMDS network, including <>. + +|[[actor_somds_v2_gateway,SOMDS V2 Gateway]] SOMDS V2 Gateway + +|Exchanges information between SOMDS and HL7 Version 2 (V2) environments. + +|=== + +The table below lists _existing_ actors that are utilized in this specification. + +//// +#TODO: VERIFY THAT THE GATEWAY ACTORS ARE FULLY ACCOUNTED FOR + ANY ADDITIONAL DEPENDENT ACTORS# +//// + +.Complete List of Existing Actors Utilized in this specification +[cols="1,2"] +|=== +|Existing Actor Name |Definition + +|[[actor_alert_consumer,Alert Consumer]] Alert Consumer +| The Alert Consumer (ACON) receives the alert from the Alert Reporter (AR) and uses the alert information strictly as a consumer of the alert being raised. There is no implementation requirement for how the ACON ultimately uses the alert information. + +|[[actor_alert_manager,Alert Manager]] Alert Manager +| The Alert Manager (AM) receives the alerts from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC), and optionally, provides the alert to the Alert Archiver (AA) or Alert Consumer (ACON) upon subscription. + +|[[actor_alert_reporter,Alert Reporter]] Alert Reporter +| This actor originates the alert (an alarm, either physiological or technical, or an advisory). + +|[[actor_device_observation_consumer,Device Observation Consumer]] Device Observation Consumer +| The actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both. + +|[[actor_device_observation_reporter,Device Observation Reporter]] Device Observation Reporter +| The Device Observation Reporter (DOR) receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics. + + +| Time Client + +| Establishes time synchronization with one or more Time Servers using the NTP protocol and either the NTP or SNTP algorithms. Maintains the local computer system clock synchronization with UTC based on synchronization with the Time Servers. + +|=== diff --git a/asciidoc/front-matter/summary-transactions.adoc b/asciidoc/front-matter/summary-transactions.adoc new file mode 100644 index 00000000..df557876 --- /dev/null +++ b/asciidoc/front-matter/summary-transactions.adoc @@ -0,0 +1,181 @@ + +// [appendix#vol0_appendix_b_transactions,sdpi_offset=B] +// === Transactions + +[%noheader] +[%autowidth] +[cols="1"] +|=== +|Add the following *_new or modified_* transactions to the IHE Technical Frameworks General Introduction https://profiles.ihe.net/GeneralIntro/ch-B.html[Appendix B]. +|=== + +//// + +#TODO: The syntax in the following table does not work when referenced; you cannot have [[...]] [[...]] back to back without some text in between. Each entry needs to be modified to enable proper use of the block IDs# + +//// + +[cols="1,2,3"] +|=== +|New Transaction Number |New Transaction Name |Definition + +.^| [[vol0_transaction_summary_dev_23,DEV-23 Announce Network Presence]] +[[transaction_number_dev_23,DEV-23]] DEV-23 +| [[transaction_name_announce_network_presence,Announce Network Presence]] Announce Network Presence +| +include::../volume2/dev-23/tf2-dev-23-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_24,DEV-24 Discover Network Topology]] +[[transaction_number_dev_24,DEV-24]] DEV-24 +| [[transaction_name_discover_network_topology,Discover Network Topology]] Discover Network Topology +| +include::../volume2/dev-24/tf2-dev-24-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_25,DEV-25 Discover BICEPS Services]] +[[transaction_number_dev_25,DEV-25]] DEV-25 +| [[transaction_name_discover_biceps_services,Discover BICEPS Services]] Discover BICEPS Services +| +include::../volume2/dev-25/tf2-dev-25-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_26,DEV-26 Discover System Context and Capabilities]] +[[transaction_number_dev_26,DEV-26]] DEV-26 +| [[transaction_name_discover_system_context_and_capabilities,Discover System Context and Capabilities]] Discover System Context and Capabilities +| Deferred to a future version of SDPi +// include::../volume2/dev-26/tf2-dev-26-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_27,DEV-27 Manage BICEPS Subscription]] +[[transaction_number_dev_27,DEV-27]] DEV-27 +| [[transaction_name_manage_biceps_subscription,Manage BICEPS Subscription]] Manage BICEPS Subscription +| +include::../volume2/dev-27/tf2-dev-27-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_28,DEV-28 Notify Change in System Context and Capabilities]] +[[transaction_number_dev_28,DEV-28]] DEV-28 +| [[transaction_name_notify_change_in_system_context_and_capabilities,Notify Change in System Context and Capabilities]] Notify Change in System Context and Capabilities +| +include::../volume2/dev-28/tf2-dev-28-summary.adoc[] +.^| [[vol0_transaction_summary_dev_29,DEV-29 Publish BICEPS Update Reports]] DEV-29 +| [[transaction_name_publish_biceps_update_reports,Publish BICEPS Update Reports]] Publish BICEPS Update Reports +| +include::../volume2/dev-29/tf2-dev-29-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_30,DEV-30 Retrieve BICEPS Content]] +[[transaction_number_dev_30,DEV-30]] DEV-30 +| [[transaction_name_retrieve_biceps_content,Retrieve BICEPS Content]] Retrieve BICEPS Content +| +include::../volume2/dev-30/tf2-dev-30-summary.adoc[] +.^| [[vol0_transaction_summary_dev_31,DEV-31 Set Provider State]] +[[transaction_number_dev_31,DEV-31]] DEV-31 +| [[transaction_name_set_provider_state,Set Provider State]] Set Provider State +| Deferred to a future version of SDPi +// include::../volume2/dev-31/tf2-dev-31-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_32,DEV-32 Retrieve Archive Data]] +[[transaction_number_dev_32,DEV-32]] DEV-32 +| [[transaction_name_retrieve_archive_data,Retrieve Archive Data]] Retrieve Archive Data +| +include::../volume2/dev-32/tf2-dev-32-summary.adoc[] +.^| [[vol0_transaction_summary_dev_33,DEV-33 Retrieve Localization Information]] +[[transaction_number_dev_33,DEV-33]] DEV-33 +| [[transaction_name_retrieve_localization_information,Retrieve Localization Information]] Retrieve Localization Information +| +include::../volume2/dev-33/tf2-dev-33-summary.adoc[] + +//| [[vol0_transaction_summary_dev_34,DEV-34 Announce Network Departure]] DEV-34 +//| [[transaction_name_announce_network_departure,Announce Network Departure]] Announce Network Departure +//| +//include::../volume2/dev-34/tf2-dev-34-summary.adoc[] +.^| DEV-34 | _Reserved_ | +//include::../volume2/dev-34/tf2-dev-34-summary.adoc[] +.^| [[vol0_transaction_summary_dev_35,DEV-35 Establish Medical Data Exchange]] +[[transaction_number_dev_35,DEV-35]] DEV-35 +| [[transaction_name_establish_medical_data_exchange,Establish Medical Data Exchange]] Establish Medical Data Exchange +| +include::../volume2/dev-35/tf2-dev-35-summary.adoc[] +.^| [[vol0_transaction_summary_dev_36,DEV-36 Publish Medical Data]] +[[transaction_number_dev_36,DEV-36]] DEV-36 +| [[transaction_name_publish_medical_data,Publish Medical Data]] Publish Medical Data +| +include::../volume2/dev-36/tf2-dev-36-summary.adoc[] +.^| [[vol0_transaction_summary_dev_37,DEV-37 Retrieve Medical Data]] +[[transaction_number_dev_37,DEV-37]] DEV-37 +| [[transaction_name_retrieve_medical_data,Retrieve Medical Data]] Retrieve Medical Data +| +include::../volume2/dev-37/tf2-dev-37-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_38,DEV-38 Establish Medical Alert Exchange]] +[[transaction_number_dev_38,DEV-38]] DEV-38 +| [[transaction_name_establish_medical_alert_exchange,Establish Medical Alert Exchange]] Establish Medical Alert Exchange +| +include::../volume2/dev-38/tf2-dev-38-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_39,DEV-39 Publish Medical Alert Update]] +[[transaction_number_dev_39,DEV-39]] DEV-39 +| [[transaction_name_publish_medical_alert_update,Publish Medical Alert Update]] Publish Medical Alert Update +| +include::../volume2/dev-39/tf2-dev-39-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_40,DEV-40 Retrieve Medical Alert Status]] +[[transaction_number_dev_40,DEV-40]] DEV-40 +| [[transaction_name_retrieve_medical_alert_status,Retrieve Medical Alert Status]] Retrieve Medical Alert Status +| +include::../volume2/dev-40/tf2-dev-40-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_41,DEV-41 Manage Medical Alert Delegation]] +[[transaction_number_dev_41,DEV-41]] DEV-41 +| [[transaction_name_manage_medical_alert_delegation,Manage Medical Alert Delegation]] Manage Medical Alert Delegation +| Deferred to a future version of SDPi +// include::../volume2/dev-41/tf2-dev-41-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_42,DEV-42 Delegate Medical Alert]] +[[transaction_number_dev_42,DEV-42]] DEV-42 +| [[transaction_name_delegate_medical_alert,Delegate Medical Alert]] Delegate Medical Alert +| Deferred to a future version of SDPi +// include::../volume2/dev-42/tf2-dev-42-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_43,DEV-43 Update Alert Acknowledgement Status]] +[[transaction_number_dev_43,DEV-43]] DEV-43 +| [[transaction_name_update_alert_acknowledgement_status,Update Alert Acknowledgement Status]] Update Alert Acknowledgement Status +| Deferred to a future version of SDPi +// include::../volume2/dev-43/tf2-dev-43-summary.adoc[] + + +.^| [[vol0_transaction_summary_dev_44,DEV-44 Manage Medical External Control]] +[[transaction_number_dev_44,DEV-44]] DEV-44 +| [[transaction_name_manage_medical_external_control,Manage Medical External Control]] Manage Medical External Control +| Deferred to a future version of SDPi +// include::../volume2/dev-44/tf2-dev-44-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_45,DEV-45 Invoke Medical Control Services]] +[[transaction_number_dev_45,DEV-45]] DEV-45 +| [[transaction_name_invoke_medical_control_services,Invoke Medical Control Services]] Invoke Medical Control Services +| Deferred to a future version of SDPi +// include::../volume2/dev-45/tf2-dev-45-summary.adoc[] + + +.^| [[vol0_transaction_summary_dev_46,DEV-46 Update Network Presence]] +[[transaction_number_dev_46,DEV-46]] DEV-46 +| [[transaction_name_update_network_presence,Update Network Presence]] Update Network Presence +| +include::../volume2/dev-46/tf2-dev-46-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_47,DEV-47 Retrieve Network Presence]] +[[transaction_number_dev_47,DEV-47]] DEV-47 +| [[transaction_name_retrieve_network_presence,Retrieve Network Presence]] Retrieve Network Presence +| +include::../volume2/dev-47/tf2-dev-47-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_48, DEV-48 Establish Distributed Alarm System]][[transaction_number_dev_48, DEV-48]] DEV-48 +| [[transaction_name_establish_distributed_alarm_system, Establish Distributed Alarm System]] Establish Distributed Alarm System +| +include::../volume2/dev-48/tf2-dev-48-summary.adoc[] + +.^| [[vol0_transaction_summary_dev_49, DEV-49 End Distributed Alarm System]][[transaction_number_dev_49, DEV-49]] DEV-49 +| [[transaction_name_end_distributed_alarm_system, End Distributed Alarm System]] End Distributed Alarm System +| +include::../volume2/dev-49/tf2-dev-49-summary.adoc[] + +.^| DEV-50 | _Reserved_ | + +|=== + diff --git a/asciidoc/front-matter/terms-definitions.adoc b/asciidoc/front-matter/terms-definitions.adoc new file mode 100644 index 00000000..75863bec --- /dev/null +++ b/asciidoc/front-matter/terms-definitions.adoc @@ -0,0 +1,22 @@ + + +[#clause_terms_definitions_acronyms,sdpi_offset=clear] += Terms, Definitions & Acronyms + +include::glossary.adoc[] + + +[#clause_requirements_terms] +=== Requirements Terms + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *Editor's Note*: + +This section *_will provide_* a defined set of requirements terminology and metadata that is required in order to ensure consistency and processing / automation of requirements throughout the specification. + +It is differentiated from the terms listed above in that it is specifically created to support the integration of formal requirements interoperability specification content; whereas, the IHE glossary provides general terminology more at the application level that is used throughout all IHE technical frameworks and profile specifications. + +|=== diff --git a/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc b/asciidoc/front-matter/tf1-ch-b-ref-standards-conformance.adoc similarity index 93% rename from asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc rename to asciidoc/front-matter/tf1-ch-b-ref-standards-conformance.adoc index a266dded..cf400a82 100644 --- a/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc +++ b/asciidoc/front-matter/tf1-ch-b-ref-standards-conformance.adoc @@ -1,16 +1,16 @@ [appendix#vol1_appendix_b_references,sdpi_offset=B] -== References +// == References [%noheader] [%autowidth] [cols="1"] |=== -| *{supplement_note}*: The inclusion of a References appendix is unique for IHE Technical Framework specifications. +| *{standard_note}*: The inclusion of a References appendix is unique for IHE Technical Framework specifications. Typically, referenced standards sections are distributed throughout the specifications where appropriate; however, standards from other organizations (e.g., IEEE, ISO, IEC) typically have a "Normative References" clause and when desired a "Bibliography" clause. Also, integration of explicit standards' <> specifications (e.g., <> <> tables) is unique, but needed to support requirements interoperability. -Ultimately, the content of this appendix may be rearranged and even relocated; however, for early versions of the SDPi supplement, it has proven helpful, and even of critical importance and value. +Ultimately, the content of this appendix may be rearranged and even relocated; however, for early versions of the SDPi standard, it has proven helpful, and even of critical importance and value. |=== // Appendix B @@ -21,7 +21,7 @@ Ultimately, the content of this appendix may be rearranged and even relocated; h [%autowidth] [cols="1"] |=== -| *{supplement_note}*: The standards listed in this section are predominantly published. +| *{standard_note}*: The standards listed in this section are predominantly published. However, in the current version, three of them are unpublished drafts and are hence subject to requirement changes once they are published: <>, <> and <>. No content from those three standards - including their requirements - is normatively used in the current version. |=== @@ -104,7 +104,7 @@ No content from those three standards - including their requirements - is norma [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// @@ -118,7 +118,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// @@ -127,25 +127,25 @@ a| *{supplement_note}*: This section intentionally left blank for the current v // IEEE 11073-10207:2017 ICS -include::conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc[] +include::../volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10207-2017.adoc[] // ISO/IEEE 11073-10700:2022 ICS -include::conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10700-2022.adoc[] +include::../volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10700-2022.adoc[] // ISO/IEEE 11073-10701:2022 ICS -include::conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10701-2022.adoc[] +include::../volume1/conformance-statements/tf1-ch-c-conformance-statement-ieee-11073-10701-2022.adoc[] // Appendix B.x -=== Bibliography +== Bibliography In addition to Referenced Standards, which include normative requirements and capabilities that this technical framework utilizes, there are other standards, specifications, publications, presentations, materials, etc. that have proven valuable in both developing and understanding the framework's content. This list identifies those items, including many of which are referenced throughout the specifications. NOTE: The subcategories for the following sections are solely intended to provide organization to the list of entries, facilitating the use of this section. [bibliography] -==== Media (non-standards) References +=== Media (non-standards) References The following bibliographic references include graphics, "infographic", and similar media. @@ -153,7 +153,7 @@ The following bibliographic references include graphics, "infographic", and simi [bibliography] -==== Standards & Publications +=== Standards & Publications The following bibliographic references include standards that are related to this specification but do not contain normative requirements, as well as papers that are useful in understanding related concepts. @@ -177,7 +177,7 @@ metalanguage - Extended BNF, 15 December 1996, available at https://standards.is * [[[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 +=== Presentations The following bibliographic references include slide decks and recordings that are helpful in understanding these specifications. diff --git a/asciidoc/sdpi-standard-intro.adoc b/asciidoc/sdpi-standard-intro.adoc deleted file mode 100644 index 2490194a..00000000 --- a/asciidoc/sdpi-standard-intro.adoc +++ /dev/null @@ -1,149 +0,0 @@ -:supplement_note: SDPi {ihe_supplement_sdpi_revision_short} Supplement Note - -[#supplement_clause_introduction_to_supplement,sdpi_offset=clear] -= Introduction to this Standard - -[%noheader] -[%autowidth] -[cols="1"] -|=== -a| *SDPi {ihe_supplement_sdpi_revision_short} Standard -- _STU / TI Version_ -- Note*: - -This version of the SDPi 2.3 Standard for Trial Use (HL7 STU) / Trial Implementation (IHE TI) supplement is the 3rd release in 2025, continuing the objective to provide three to four releases each year that include both _incremental_ updates (e.g., editorial "fixes"), ballot comment resolutions (e.g., from HL7 ballot cycles), and additional capability enhancements. -For this release, key changes include: - -1. Added new extensions _ReportSequence_ and _Relations_ -2. Added conformity statement tables for SPDi-defined requirements -3. Added semantic markup to support rich artefact generation - -Numerous other corrections and enhancements are included. - -All changes incorporated in a release are managed through Github Issues and reviewed Pull Requests. -For a list of those related to this release, see <> below. -For HL7 ballot comment resolution, links are made from HL7 ballot Jira tickets to IHE DEV.SDPi Github Issues that then enable tracking of the comment resolution implementation in a specific release. - - -NOTE: This supplement also includes both normative and informative references to other specifications (see <>), 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 mature development stage; however, some requirements from that pre-standard may be included (non-normatively) 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. -These known limitations and forward-looking content include: - -. Releases along with the planned capability additions are managed in the project's https://github.com/IHE/DEV.SDPi/milestones[DEV.SDPi milestones]; -. This supplement includes four 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* -- starting with SDPi 1.1 and subsequent, the approach for the IHE open / closed issues section was transitioned to utilize https://github.com/IHE/DEV.SDPi/issues[Github Issues] that are related to specific releases; each release updates the changelog file, detailing what is Added, Changed or Removed; -. *Requirements boxes* (e.g., "R1234") are included 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_*; documentation is provided in <>, 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; -. This supplement is currently rendered as a *"long form"* document -- one single HTML file; however, in subsequent versions the intent is to consider a multi-page / file HTML rendering + addition of a tabbed menu for navigating the sections of the supplement; -. *{supplement_note}* boxes are provided throughout the document to help guide reviewers and implementers. - -|=== - -// Forward declarations of common labels & acronyms & variables -include::document-declarations.adoc[] - -// Define oids for referenced standards -include::std-oid-definitions.adoc[] - -[#supplement_clause_sdpi_supplement_overview] -== SDPi Standard Overview - -[#supplement_clause_sdpi_supplement_organization] -=== SDPi Organization - -This IHE Devices Technical Framework standard 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 three IHE DEV TF volumes, including: - -*TF-1 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 - -*TF-2 Transactions* - -* Extensive new set of transactions based on IEEE 11073 Service-oriented Device Connectivity (SDC) medical device interoperability standards. -* Related appendices, for example the specialized use of web services messaging for device communication and gateways to other protocols or profiles - -*TF-3 Content Modules* - -* New content covering the application of IEEE 11073 SDC semantic standards to device content modules, with a primary focus on specifications related to the IEEE 11073-10207 BICEPS standard. - -NOTE: As explained in the https://profiles.ihe.net/GeneralIntro/ch-7.html#7.5[IHE Technical Framework Document Conventions], the acronym TF stands for Technical Framework, whereas the number immediately behind the hyphen in the "TF-X" notation stands for the volume number within a Technical Framework. - -[#supplement_clause_mapping_clinical_scenarios_to_profile_requirements] -=== Use Cases: Mapping Clinical Scenarios to Profile Requirements -IHE technical framework integration profile specifications include use case sections to ensure that the technical solutions are rooted in real-world application requirements. -These sections typically include a basic description of use case scenarios, identify the key systems that exchange information, application-level detail of the information exchanged, and perhaps even some sequence diagrams. -This information may also be used to drive the test cases that are used for conformity assessment, ensuring that the resulting specification implementation meets the intended needs. - -This supplement includes this same organization; however, it also defines a set of general, non-profile-specific clinical use cases that provide requirements, which may be mapped to multiple SDPi integration profiles. -Section <> 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 requirements 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. -Extensive notes and discussion materials are provided on the project's HL7 Confluence site, including a https://confluence.hl7.org/pages/viewpage.action?pageId=113674346#LibrarywithEVERYTHINGyoueverwantedtoknow...-GeneralUpdate&BriefingPresentations[Library with extensive presentations and other materials]. -This Library also includes *_briefings (slides and recordings) to provide background for those reviewing the specification_*. - -The joint IHE-HL7 devices team leveraged tools from both organizations, as well as participated jointly throughout the project's multi-year efforts. - -The methods currently employed are provided in the wiki article: https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#program-coordination--co-working-spaces[Program Coordination & Co-Working Spaces]. - -[#supplement_clause_supplement_support_for_ri_mc_rr_using_asciidoc] -=== Supplement Support for RI+MC+RR using AsciiDoc -In addition to the supplement's technical specification content, a development approach has been advanced that represents added value to adopters and implementers over the traditional document oriented approach. -These are referred to as: - -[none] -. *_Requirements Interoperability + Model Centric + Regulatory Ready_* - -Or *RI+MC+RR* for short. - -These three objectives may be summarized as follows: - -[none] -* *Requirements Interoperability (RI)* -[none] -** 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 -* *Regulatory Ready (RR)* -[none] -** 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. -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]. -See also related discussions on the Gemini Project's https://confluence.hl7.org/x/XhPUB[Pathway to an Ecosystem of Plug-and-Trust Products]. - - -[#supplement_clause_requirements_glossary] -=== Requirements Glossary - - -[%noheader] -[%autowidth] -[cols="1"] -|=== -a| *Editor's Note*: - -This "glossary" provides a defined set of requirements terminology and meta data is required in order to ensure consistency and processing / automation of requirements throughout the specification. - -It is differentiated from the IHE TF-0 Glossary in that it is specifically created to support the integration of formal requirements interoperability specification content; whereas, the IHE glossary provides general terminology more at the application level that is used throughout all IHE technical frameworks and profile specifications. - -|=== - diff --git a/asciidoc/sdpi-standard-issues.adoc b/asciidoc/sdpi-standard-issues.adoc deleted file mode 100644 index f9cfdde1..00000000 --- a/asciidoc/sdpi-standard-issues.adoc +++ /dev/null @@ -1,38 +0,0 @@ - -[sdpi_offset=clear] -[#sdpi_issue_management] -== SDPi Issue Management - -[sdpi_offset=clear] -=== SDPi Issue Management - -*Standalone SDPi:* _Consider how this might change from STU/TI to Normative/FT, and organize it accordingly._ - -All SDPi standard issues are tracked in the https://github.com/IHE/DEV.SDPi/issues[IHE Github DEV.SDPi repository Issues section]. -Filter the issues on their "state" to see them. + - -* To see the full list of OPEN issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen -* To see the full list of CLOSED issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed - -For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the https://github.com/IHE/DEV.SDPi/wiki[_IHE SDPi wiki_]. - -[sdpi_offset=clear] -=== Open Issues - -The issues listed in this section or in https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen are open, and hence not yet ready for inclusion in the IHE DEV Technical Framework and not subject to comment or review. - -//==== Open Issues - -// open issues are inserted here - -//==== Topic of Interests - -// toi issues are inserted here - -[sdpi_offset=clear] -=== Closed Issues - -The issues listed in this section or in https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed are closed. - -// closed issues are inserted here - diff --git a/asciidoc/sdpi-standard.adoc b/asciidoc/sdpi-standard.adoc index 0e9c803e..3582e619 100644 --- a/asciidoc/sdpi-standard.adoc +++ b/asciidoc/sdpi-standard.adoc @@ -18,8 +18,6 @@ :source-highlighter: highlight.js :highlightjsdir: js/highlight -// STANDALONE SDPi: Deferred is the refactoring of all "supplement" to "standard" language - // Set the document attribute to automatically generate // actor transactions table from semantic markup. Unset // to use manual tables. @@ -30,20 +28,22 @@ :sdpi_milestone_review: SDPi 2.3 Review :sdpi_version_major: 2 -:sdpi_version_minor: 4 +:sdpi_version_minor: 5 :sdpi_version_revision: 0 // STANDALONE SDPi: QUESTION: Do we rework these to gemini_standard -:ihe_supplement_sdpi_revision: {sdpi_version_major}.{sdpi_version_minor}.{sdpi_version_revision} -:ihe_supplement_sdpi_revision_short: {sdpi_version_major}.{sdpi_version_minor} -:ihe_supplement_sdpi_revision_date: {localdatetime} -:ihe_supplement_sdpi_revision_label: Standard for Trial Use -:ihe_supplement_sdpi_publication_month: December 19, 2025 -:ihe_supplement_sdpi_public_comment_submission_deadline: N/A +:ihe_standard_sdpi_revision: {sdpi_version_major}.{sdpi_version_minor}.{sdpi_version_revision} +:gemini_standard_sdpi_revision_short: {sdpi_version_major}.{sdpi_version_minor} +:ihe_standard_sdpi_revision_date: {localdatetime} +:ihe_standard_sdpi_revision_label: Standard for Trial Use +:ihe_standard_sdpi_publication_month: December 19, 2025 +:ihe_standard_sdpi_public_comment_submission_deadline: N/A // Oid, assigned by IHE-DEV, for the SDPi specification // https://wiki.ihe.net/index.php/PCD_OID_Management :sdpi-parent-oid: 1.3.6.1.4.1.19376.1.6.2.10 +:standard_note: SDPi {gemini_standard_sdpi_revision_short} Standard Note + {empty} + ifeval::["{backend}" == "html5"] ++++ @@ -64,13 +64,13 @@ ifeval::["{backend}" == "html5"]

Gemini

-

Technical Framework Standard

+

Technical Framework Profile Standard

Service-oriented Device Point-of-care

Interoperability (SDPi)

-

Revision {ihe_supplement_sdpi_revision} — {ihe_supplement_sdpi_revision_label}

+

Revision {ihe_standard_sdpi_revision} — {ihe_standard_sdpi_revision_label}

("Standalone" SDPi Standard - For Review)

++++ @@ -82,19 +82,17 @@ endif::[] [frame=none,grid=none] |=== | *Publication Date:* -| {ihe_supplement_sdpi_publication_month} +| {ihe_standard_sdpi_publication_month} | *Build Date:* -| {ihe_supplement_sdpi_revision_date} +| {ihe_standard_sdpi_revision_date} | *Author:* | Gemini Medical Device Interoperability Program Team (Joint HL7 & IHE Devices Working Groups) -// STANDALONE SDPi: Should this field be included? What address? Or one for IHE and one for HL7? -| *Email:* -| DEV@ihe.net +| *Issues / Questions:* +| Submit a _New issue_ at https://github.com/IHE/DEV.SDPi/issues[Gemini DEV.SDPi GitHub Issues] -*Standalone SDPi:* _Should this email contact be included? If so, what address(es)? One for IHE and one for HL7?_ |=== {empty} + @@ -109,43 +107,121 @@ ifeval::["{backend}" == "html5"] //A PDF version of the specification is available upon request. endif::[] -[#supplement_clause_foreword,sdpi_offset=clear] -= Foreword - -This Gemini standard is a joint development effort between Health Level Seven International (HL7) and Integrating the Healthcare Enterprise (IHE) devices working groups. -Its development and publication adheres to the consensus standards processes of both HL7, an ANSI accredited standards development organization, and IHE. -The title of this document, "Technical Framework *_Standard_*", reflects its unique status as a Gemini specification, utilizing the IHE Technical Framework organization and elements (e.g., integration profiles, actors, transactions, content modules), but processed as an HL7 specification that will be published as a "standalone" standard and will persist even when its status transitions to normative standard (HL7) or Final Text (IHE). - -To facilitate integration with the companion IHE Devices Technical Framework (final text) specification, a companion to this standard will be created for each edition: SDPi "Technical Framework Supplement", which will be organized according to IHE style guidelines, but it will be in major section outline only, with each section including a note indicating where the content is located in the published Gemini Technical Framework ("standalone") Standard document. -Given its alignment with the companion IHE specification, some section numbers are skipped in this document to facilitate its intended integration into the above-mentioned "supplement". -Skipped section numbers are already present in the Devices Technical Framework and will not require changes due to the incorporation of the supplement once it transitions to normative standard / final text status. - -Additionally, some content that may otherwise be only referenced by a "supplement" document and defined elsewhere in the existing technical framework, will be incorporated in this specification to ensure that it is internally cohesive and does not force the reader to unnecessarily consult other documents. - -Publication as a Standard for *Trial* Use (HL7) or *Trial* Implementation (IHE) reflects the continuous cycle of development, balloting and publication of the specification, to address addition of new capabilities as well as identified safety, effectiveness and security issues and enhancements. -Product developers are encouraged to use the standard, recognizing the potential impact of this continuous development cycle and its status as a _"trial use"_ standard. - - -This supplement is published on {ihe_supplement_sdpi_publication_month} for Trial Implementation and may be available for testing at subsequent IHE or HL7 testing events, such as an IHE Connectathon. -The standard may be amended based on the results of testing. -Following successful testing and implementation maturity, it will transition to a normative standard, and the companion IHE supplement will be incorporated into the Devices Technical Framework. -Comments are invited and can be submitted at https://www.ihe.net/DEV_Public_Comments/[Devices Public Comments] or by submitting a https://github.com/IHE/DEV.SDPi/issues/new/choose[GitHub Issue]. - -General information about IHE can be found at http://www.ihe.net/[IHE.net], and about HL7 can be found at https://www.hl7.org/index.cfm[HL7.org]. - -General information about the HL7 Devices Working Group can be found at https://www.hl7.org/Special/committees/healthcaredevices/index.cfm[HL7.org/healthcaredevices], and the IHE Devices domain can be found at https://www.ihe.net/ihe_domains/[IHE Domains]. - -Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at https://www.ihe.net/resources/profiles/[Profiles] and https://www.ihe.net/about_ihe/ihe_process/[IHE Processes]. +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *Gemini SDPi {gemini_standard_sdpi_revision_short} "Standalone" Standard -- Release & Drafting Notes*: + +=== Release Note: +This version of the SDPi {gemini_standard_sdpi_revision_short} Standard for Trial Use (HL7 STU) / Trial Implementation (IHE TI) standard is the 3rd release in 2025, continuing the objective to provide three to four releases each year that include both _incremental_ updates (e.g., editorial "fixes"), ballot comment resolutions (e.g., from HL7 ballot cycles), and additional capability enhancements. + +This Gemini SDPi {gemini_standard_sdpi_revision_short} release is the first time the specification has been separated into two separate documents: + +. *sdpi-standard.html* -- contains all the normative content from the previous releases; however, the front matter is reorganized in alignment with other standards templates (e.g., Scope, Introduction / Overview, References, Acronyms, etc.). +It still maintains the IHE Technical Framework organizational elements (e.g., Volume 1 Integration Profiles, Volume 2 Transactions, etc.); however, elements that are solely intended for an IHE Technical Framework Supplement (e.g., directions for how to integrate a section into the IHE Devices Technical Framework - Final Text) are removed and only contained in the new supplement document +. *sdpi-supplement.html* -- contains the main outline of the standard document; however, all the normative content is referenced in the supplement to the appropriate location in the standard. +The supplement includes all the rubric information needed for ultimately integrating it into the IHE Devices Technical Framework. + +For this release, key changes include: + +1. Resolution of all HL7 MAY 2026 Ballot Comments +2. New History Service option with related transaction DEV-32 +3. "Standalone" SDPi -- initial creation of two documents: Gemini Standard + IHE Supplement +4. Support semantic markup for deprecating requirements, transactions, use-cases, profiles, content modules and actors +5. Updates related to the corrected SDC BICEPS standard corrigendum +6. Clarifications and corrections + +All changes incorporated in a release are managed through Github Issues and reviewed Pull Requests. +For a list of those related to this release, see +//<> +below. +For HL7 ballot comment resolution, links are made from HL7 ballot Jira tickets to IHE DEV.SDPi Github Issues that then enable tracking of the comment resolution implementation in a specific release. + +NOTE: This standard also includes both normative and informative references to other specifications (see <>), 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 mature development stage; however, some requirements from that pre-standard may be included (non-normatively) 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. +These known limitations and forward-looking content include: + +. Releases along with the planned capability additions are managed in the project's https://github.com/IHE/DEV.SDPi/milestones[DEV.SDPi milestones]; +. This standard includes four 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* -- starting with SDPi 1.1 and subsequent, the approach for the IHE open / closed issues section was transitioned to utilize https://github.com/IHE/DEV.SDPi/issues[Github Issues] that are related to specific releases; each release updates the changelog file, detailing what is Added, Changed or Removed; +. *Requirements boxes* (e.g., "R1234") are included 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 standard_*; documentation is provided in <>, including discussion related to how it will be expanded in future versions of the standard; +. *_<> Sections_* (see <>) are included in the specification; however, their use and content will be significantly extended in future versions; +. This standard is currently rendered as a *"long form"* document -- one single HTML file; however, in subsequent versions the intent is to consider a multi-page / file HTML rendering + addition of a tabbed menu for navigating the sections of the standard; +. *{standard_note}* boxes are provided throughout the document to help guide reviewers and implementers. +This release of the standard+supplement documents is still in process, as the "Drafting Note" below indicates! +The outline of this standard, though, will be as follows: + +// ***************************************************************** + +. *Overview* +[none] +.. *Scope* +.. *Purpose* +[none] +.. (content from current TF-1:2.3.1.1 and similar) +.. (Copyright and other related content from supplement) +. *Introduction & Overview* +[none] +.. *_Gemini Technical Framework Profile Standard_* +[none] +... (define what a Gemini TF Profile Standard ... is!) +... (organization & conventions - section numbering, ...) +... (What & why AsciiDoc) +.. *_SDPi Overview_* +[none] +... (refactor content from TF-1:2 and elsewhere) +... (Use Cases? Keep TF-1C or refactor here?) +... Summary of SDPi Actors & Transactions +. *Terms, Definitions & Acronyms* +[none] +.. (content from TF-0, Forward declarations, ... ) +. *References* +[none] +.. (Content from TF-1B) +. ... +. [.line-through]#*Volume 1 Integration Profiles*# +. [.line-through]#*Volume 2 Transactions*# +. [.line-through]#*Volume 3 Content Modules*# + + +=== "Standalone" SDPi Drafting Note: + +Editorial Task List (prioritized) for this Supplement: + +. [.line-through]#Title Page - Update & review# +.. [.line-through]#Change Contact from DEV@IHE.NET to IHE SDPi GitHub Issues link# +. [.line-through]#Find and update all uses of "supplement" throughout current document# +.. [.line-through]#In labels used for referencing# +.. [.line-through]#In standard note sections# +.. [.line-through]#... ?# +. Create common sdpi-version.adoc that can be shared between the two documents +.. Also refactor gemini_standard_ and ihe_supplement_ to common labels +.. Also refactor standard_clause_ to clause_ +. Refactor front matter not IHE TF based, but for a standalone document: +.. [.line-through]#Remove TF-0 content (supplement only)# +.. Introduction: Gemini, Gemini TF Profile Standard, SDPi in particular; +... Include Unique Features of TF Profile Standard (incl. embedded requirements, ... ) +.. Refactor any IHE TF template content to be "standalone" where appropriate +.. Update section 2 overview of SDPi to a simple overview +.. Add Normative References? or Definitions section? - reference to Appendix B +.. Refactor forward references content from early in document to a more "permanent" location! +. Move all SUPPLEMENT INSTRUCTIONS from this document to the supplement - "Standard Note" ... +. Add Standard release punch-list that includes updating Supplement content to keep in sync +. ... -The current version of the IHE Devices Technical Framework can be found at https://profiles.ihe.net/DEV/[DEV Technical Framework]. +|=== -include::sdpi-standard-intro.adoc[] +include::front-matter/forward.adoc[] -include::sdpi-standard-issues.adoc[] +include::front-matter/overview.adoc[] -// = Volume 0 -- IHE Technical Frameworks General Introduction +include::front-matter/terms-definitions.adoc[] -include::volume0/tf0-main.adoc[] +include::front-matter/references.adoc[] // = Volume 1 -- Profiles @@ -159,3 +235,4 @@ include::volume2/tf2-main.adoc[] include::volume3/tf3-main.adoc[] +include::conformance/conformance.adoc[] \ No newline at end of file diff --git a/asciidoc/sdpi-supplement.adoc b/asciidoc/sdpi-supplement.adoc index dddaeebc..0ee7ad1d 100644 --- a/asciidoc/sdpi-supplement.adoc +++ b/asciidoc/sdpi-supplement.adoc @@ -20,16 +20,16 @@ // Set the document attribute to automatically generate // actor transactions table from semantic markup. Unset -// to use manual tables. +// to use manual tables. // https://docs.asciidoctor.org/asciidoc/latest/attributes/unset-attributes/ :markup-actor-transactions-table: -:sdpi_milestone_publication: SDPi 2.4 Publication -:sdpi_milestone_review: SDPi 2.4 Review +:sdpi_milestone_publication: SDPi 2.5 Publication +:sdpi_milestone_review: SDPi 2.5 Review :sdpi_version_major: 2 -:sdpi_version_minor: 4 -:sdpi_version_revision: 1 +:sdpi_version_minor: 5 +:sdpi_version_revision: 0 :ihe_supplement_sdpi_revision: {sdpi_version_major}.{sdpi_version_minor}.{sdpi_version_revision} :ihe_supplement_sdpi_revision_short: {sdpi_version_major}.{sdpi_version_minor} :ihe_supplement_sdpi_revision_date: {localdatetime} @@ -99,6 +99,42 @@ ifeval::["{backend}" == "html5"] //A PDF version of the specification is available upon request. endif::[] +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *Gemini SDPi {ihe_supplement_sdpi_revision_short} "Standalone" Supplement -- Release & Drafting Notes*: + +=== Release Note +This release of SDPi is the first version that includes a separate _sdpi-supplement_ specification (this document) that was created out of the previous released version and aligned with the current _sdpi-standard_ document. +This document is intended to provide the necessary organization and summary content that can ultimately be integrated into the IHE DEV TF "final text" normative version. +When that integration to the DEV TF occurs, this "supplement" will no longer be needed and will be deprecated; however, the "standard" document will always persist. + +NOTE: This supplement has the same revision label as the associated standard revision to which it is aligned. +It may be that when a DEV TF integration occurs for those aspects of SDPi that are "final text", other capabilities will be in active development, thus requiring the need for this supplement -- potentially, for a long time!" + +The complete detailed normative content will remain in the sdpi-standard document as it has evolved in recent years; however, that document will be designed so that it will always remain -- standalone -- and will not be integrated into some other document. + +For a summary of changes made to this release of the standard and related supplement, see the release note in the SDPi {ihe_supplement_sdpi_revision_short} Standard document. + +=== Drafting Note - Remaining Tasks & Open Questions +Editorial Task List (prioritized) for this Supplement: + +. [.line-through]#Move over Introduction files# +. [.line-through]#Move over TF-0 files# +. [.line-through]#Add top level outline structure for supplement document# +.. Move Clause 2 Overview content to supplement (it will stay here intact) +. [.line-through]#Change labels as appropriate / necessary to be supplement-specific so as to reduce any confusion# +. Add front matter updates per IHE TF Format but for this Supplement, explaining supplement/standalone & conceptual approach. +NOTE: The TF-1:2 content might be identical in this document. +. Add overview content for each outline section +. Add Standard -> Supplement Release Update punch list (e.g., new actors / transactions ... in TF-0 appendices) +. Migrate all supplement INSTRUCTIONS (e.g., from TF-3) to this supplement +. ... + +|=== + + [#supplement_clause_foreword,sdpi_offset=clear] = Foreword @@ -132,76 +168,28 @@ Information about the organization of IHE Technical Frameworks and Supplements a The current version of the IHE Devices Technical Framework can be found at https://profiles.ihe.net/DEV/[DEV Technical Framework]. -//// -TODO: for some reason, include macros in this file are (partially?) executed such that block processing plugins - fail due to missing input data. To avoid that, the include directions in this file has been changed from - "include::" to "include:". -//// +include::supplement/sdpi-supplement-intro.adoc[] -// STANDALONE SDPi: 1st refactoring, moved copies of these files into the supplement/ directory -// include:supplement/sdpi-supplement-intro.adoc[] - -// include:supplement/sdpi-standard-issues.adoc[] +// STANDALONE TO DO - This is a common IHE SUPPLEMENT SECTION, we should include it and mention that they are in the standard +// include::supplement/standard-issues.adoc[] // = Volume 0 -- IHE Technical Frameworks General Introduction -// STANDALONE SDPi: 1st refactoring, simply COMMENTED OUT the 3 volumes -//include:volume0/tf0-main.adoc[] +include::supplement/volume0/tf0-main.adoc[] // // = Volume 1 -- Profiles // -//include:volume1/tf1-main.adoc[] - -// Appendix A -//// -[appendix#vol1_appendix_a_requirements_management_for_p_n_t_interperability,sdpi_offset=A] -== Requirements Management for Plug-and-Trust Interoperability - -[#vol1_clause_sdpi_requirements_modeling_integration] -=== SDPi Requirements Modeling & Integration - -[#vol1_clause_appendix_a_ses_considerations_section_template] -=== SES Considerations Section Template +include::supplement/sdpi-supplement-tf1.adoc[] -// Appendix B -[appendix#vol1_appendix_b_references,sdpi_offset=B] -== References - -[%noheader] -[%autowidth] -[cols="1"] -|=== -| *{supplement_note}*: -IHE Supplement TF-1:B References Appendix content is provided in *Gemini Standard TF-1:B*. -|=== - - -include:volume1/tf1-main.adoc[] - -[%noheader] -[%autowidth] -[cols="1"] -|=== -| *{supplement_note}*: -IHE Supplement TF-1:B.1 Referenced Standards content is provided in *Gemini Standard TF-1:B.1 Referenced Standards*. -|=== - -// Appendix C - -[appendix#vol1_appendix_c_dpi_use_cases,sdpi_offset=C] -== Device Point-of-care Interoperability (DPI) Use Cases - -[#vol1_clause_appendix_c_use_case_sicdmp,sdpi_offset=4] -=== Use Case Feature {var_use_case_id}: <> (<>) // // = Volume 2 -- Transactions // -//include:volume2/tf2-main.adoc[] +include::supplement/sdpi-supplement-tf2.adoc[] + // // = Volume 3 -- Content Modules // -//include:volume3/tf3-main.adoc[] +include::supplement/sdpi-supplement-tf3.adoc[] -//// diff --git a/asciidoc/supplement/sdpi-supplement-document-declarations.adoc b/asciidoc/supplement/sdpi-supplement-document-declarations.adoc new file mode 100644 index 00000000..2260c674 --- /dev/null +++ b/asciidoc/supplement/sdpi-supplement-document-declarations.adoc @@ -0,0 +1,106 @@ + +//// + FORWARD DECLARATIONS FOR THE DOCUMENT + +NOTES: + 1) The items defined below are forward declarations to define labels for the entire document + 2) VARIABLES are used not because the content may vary (such as transaction #'s) but + 3) They can get expanded anywhere including in section headings + +//// + +[#supplement_clause_forward_declarations,sdpi_offset=clear] +== Standard Forward Declarations + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: + +The following table is included in this version of the standard to capture *_"forward" declarations of acronyms and labels_* that are used in the text but are not intended to be part of the General Introduction Appendix D Glossary. +"Forward" means that they are used BEFORE the document section in which they are formally defined. +Since AsciiDoc is a one-pass processor, forward declarations are required. + +There was no clear way of defining these replacement definitions in a way that is "under the hood" and not visible to the reader. +The following table was thus created but may be moved or otherwise implemented in subsequent standard versions. + +Suggestions appreciated! + +NOTE: Forward Declarations in the following table are being added "on demand" or when needed and not comprehensively for every acronym defined in the document that is not also included in the Glossary. + +|=== + + +[%autowidth] +[cols="^1,^2,1,^2"] +|=== +|Acronym |Label |Section Defined In | Type + +| [[acronym_aars,AARS]] AARS +| [[label_use_case_name_aars,Alerts to Alert Recording Systems]] Alerts to Alert Recording Systems +// | <> +| +| Use Case + +| [[acronym_acns,ACNS]] ACNS +| [[label_use_case_name_acns,Alerts to Clinician Notification Systems]] Alerts to Clinician Notification Systems +// | <> +| +| Use Case + +| [[acronym_agw,AGW]] AGW +| [[label_system_type_name_agw,Alert Gateway]] Alert Gateway +// | <> +| +| System Type + +| [[acronym_cs,CS]] CS +| [[label_system_type_name_cs,Central Station]] Central Station +// | <> +| +| System Type + +| [[acronym_dgw,DGW]] DGW +| [[label_system_type_name_dgw,Data Gateway]] Data Gateway +// | <> +| +| System Type + +| [[acronym_ddes,DDES]] DDES +| [[label_use_case_name_ddes,Device Data to Enterprise Systems]] Device Data to Enterprise Systems +// | <> +| +| Use Case + +| [[acronym_mdpws,MDPWS]] MDPWS +| [[label_use_case_name_mdpws,Medical Devices Communication Profile for Web Services]] Medical Devices Communication Profile for Web Services +// | ref_ieee_11073_20702_2016 <> +| +| Standard + +| [[acronym_sas,SAS]] SAS +| [[label_system_type_name_sas,Smart Alerting System]] Smart Alerting System +// | <> +| +| System Type + +| [[acronym_sicdmp,SICDmp]] SICDmp +| [[label_use_case_name_sicdmp,Standalone ICU Dashboard Multiple Patient]] Standalone ICU Dashboard Multiple Patient +// | <> +| +| Use Case + +| [[acronym_sicdsp,SICDsp]] SICDsp +| [[label_use_case_name_sicdsp,Standalone ICU Dashboard Single Patient]] Standalone ICU Dashboard Single Patient +// | <> +| +| Use Case + +| [[acronym_stad,STAD]] STAD +| [[label_use_case_name_stad,Synchronized Time Across Devices]] Synchronized Time Across Devices +// | <> +| +| Use Case + +|=== diff --git a/asciidoc/supplement/sdpi-supplement-intro.adoc b/asciidoc/supplement/sdpi-supplement-intro.adoc index 677a9941..a9fabff1 100644 --- a/asciidoc/supplement/sdpi-supplement-intro.adoc +++ b/asciidoc/supplement/sdpi-supplement-intro.adoc @@ -3,51 +3,17 @@ [#supplement_clause_introduction_to_supplement,sdpi_offset=clear] = Introduction to this Supplement -[%noheader] -[%autowidth] -[cols="1"] -|=== -a| *SDPi {ihe_supplement_sdpi_revision_short} Supplement -- _STU / TI Version_ -- Note*: - -This version of the SDPi 2.4 Standard for Trial Use (HL7 STU) / Trial Implementation (IHE TI) supplement is the 1st release in 2026, continuing the objective to provide three to four releases each year that include both _incremental_ updates (e.g., editorial "fixes"), ballot comment resolutions (e.g., from HL7 ballot cycles), and additional capability enhancements. -For this release, key changes include: - -1. Added new Distributed Alarm System option and related transactions DEV-48 and DEV-49 (a.k.a. early "pre-published" integration of the IEEE 11073-10702 standard) -2. Added OID framework to Appendix 3:Z -3. Made several corrections and clarifications - -All changes incorporated in a release are managed through Github Issues and reviewed Pull Requests. -For a list of those related to this release, see <> below. -For HL7 ballot comment resolution, links are made from HL7 ballot Jira tickets to IHE DEV.SDPi Github Issues that then enable tracking of the comment resolution implementation in a specific release. - - -NOTE: This supplement also includes both normative and informative references to other specifications (see <>), 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 mature development stage; however, some requirements from that pre-standard are included (non-normatively) 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. -These known limitations and forward-looking content include: - -. Releases along with the planned capability additions are managed in the project's https://github.com/IHE/DEV.SDPi/milestones[DEV.SDPi milestones]; -. This supplement includes four 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* -- starting with SDPi 1.1 and subsequent, the approach for the IHE open / closed issues section was transitioned to utilize https://github.com/IHE/DEV.SDPi/issues[Github Issues] that are related to specific releases; each release updates the changelog file, detailing what is Added, Changed or Removed; -. *Requirements boxes* (e.g., "R1234") are included 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_*; documentation is provided in <>, 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; -. This supplement is currently rendered as a *"long form"* document -- one single HTML file; however, in subsequent versions the intent is to consider a multi-page / file HTML rendering + addition of a tabbed menu for navigating the sections of the supplement; -. *{supplement_note}* boxes are provided throughout the document to help guide reviewers and implementers. - -|=== - // Forward declarations of common labels & acronyms & variables -include::document-declarations.adoc[] +include::sdpi-supplement-document-declarations.adoc[] // Define oids for referenced standards -include::std-oid-definitions.adoc[] +include::../std-oid-definitions.adoc[] + -[#supplement_clause_sdpi_supplement_overview] +[#clause_sdpi_supplement_overview] == SDPi Supplement Overview -[#supplement_clause_sdpi_supplement_organization] +[#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 four separate profiles: @@ -76,19 +42,19 @@ To that end, the supplement includes updates to all three IHE DEV TF volumes, in NOTE: As explained in the https://profiles.ihe.net/GeneralIntro/ch-7.html#7.5[IHE Technical Framework Document Conventions], the acronym TF stands for Technical Framework, whereas the number immediately behind the hyphen in the "TF-X" notation stands for the volume number within a Technical Framework. -[#supplement_clause_mapping_clinical_scenarios_to_profile_requirements] +[#clause_mapping_clinical_scenarios_to_profile_requirements] === Use Cases: Mapping Clinical Scenarios to Profile Requirements IHE technical framework integration profile specifications include use case sections to ensure that the technical solutions are rooted in real-world application requirements. These sections typically include a basic description of use case scenarios, identify the key systems that exchange information, application-level detail of the information exchanged, and perhaps even some sequence diagrams. This information may also be used to drive the test cases that are used for conformity assessment, ensuring that the resulting specification implementation meets the intended needs. - +//// This supplement includes this same organization; however, it also defines a set of general, non-profile-specific clinical use cases that provide requirements, which may be mapped to multiple SDPi integration profiles. Section <> 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 requirements 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] +//// +[#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. Extensive notes and discussion materials are provided on the project's HL7 Confluence site, including a https://confluence.hl7.org/pages/viewpage.action?pageId=113674346#LibrarywithEVERYTHINGyoueverwantedtoknow...-GeneralUpdate&BriefingPresentations[Library with extensive presentations and other materials]. @@ -98,7 +64,7 @@ The joint IHE-HL7 devices team leveraged tools from both organizations, as well The methods currently employed are provided in the wiki article: https://github.com/IHE/DEV.SDPi/wiki/Program-Coordination-Co-Working-Spaces#program-coordination--co-working-spaces[Program Coordination & Co-Working Spaces]. -[#supplement_clause_supplement_support_for_ri_mc_rr_using_asciidoc] +[#clause_supplement_support_for_ri_mc_rr_using_asciidoc] === Supplement Support for RI+MC+RR using AsciiDoc In addition to the supplement's technical specification content, a development approach has been advanced that represents added value to adopters and implementers over the traditional document oriented approach. These are referred to as: @@ -125,11 +91,11 @@ The SDPi {ihe_supplement_sdpi_revision} version of the supplement continues to m 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 #LINK OR TEXT#:vol1_appendix_a_requirements_management_for_p_n_t_interperability, 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]. -[#supplement_clause_requirements_glossary] +[#clause_requirements_glossary] === Requirements Glossary diff --git a/asciidoc/supplement/sdpi-supplement-std-oid-definitions.adoc b/asciidoc/supplement/sdpi-supplement-std-oid-definitions.adoc new file mode 100644 index 00000000..05d7cf49 --- /dev/null +++ b/asciidoc/supplement/sdpi-supplement-std-oid-definitions.adoc @@ -0,0 +1,19 @@ +//// +Define oids for standards referenced in requirements. +//// + +// The SDPI profile described in this documentation +:sdpi_oid.sdpi: 1.3.6.1.4.1.19376.1.6.2.10.1.1.1 + +// The SDPi plug-and-trust profile described in this documentation +:sdpi_oid.sdpi-p: 1.3.6.1.4.1.19376.1.6.2.11 + +// The SDPi alerting profile described in this documentation +:sdpi_oid.sdpi-a: 1.3.6.1.4.1.19376.1.6.2.x + +// The SDPi reporting profile described in this documentation +:sdpi_oid.sdpi-r: 1.3.6.1.4.1.19376.1.6.2.x + +// The SDPi external control profile described in this documentation +:sdpi_oid.sdpi-xC: 1.3.6.1.4.1.19376.1.6.2.x + diff --git a/asciidoc/supplement/sdpi-supplement-tf1-ch-2-overview.adoc b/asciidoc/supplement/sdpi-supplement-tf1-ch-2-overview.adoc new file mode 100644 index 00000000..56bfa18f --- /dev/null +++ b/asciidoc/supplement/sdpi-supplement-tf1-ch-2-overview.adoc @@ -0,0 +1,219 @@ +//= Devices Integration Profiles + +// 2. +[#vol1_clause_devices_integration_profiles,sdpi_offset=2] +== Devices Integration Profiles + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: This supplement is being written after the 2019 reorganization of the IHE Patient Care Devices (*PCD*) domain to the IHE Devices (*DEV*) domain. +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 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. +|=== + +// 2.2 +[#vol1_clause_ses_considerations_requirements,sdpi_offset=2] +=== Safety, Effectiveness and Security - Requirements and Considerations +IHE specifications often include sections for "Security Considerations" and "Safety Considerations", capturing both general and specific guidance and requirements for system implementers. +This standard extends these two concepts to include a third: Effectiveness. +The sections are titled "Safety, Effectiveness and Security - Requirements and Considerations" and make use of the underlying term <>. + +The background for <> is discussed in detail in <>; however, in general "<>" is used as a reference to the standards encompassed (directly and indirectly by reference) in <>, including <> and <>. +These standards are primarily, though not exclusively, focused on *_risk management of health software_* (including <>) *_and medical devices that are deployed on various kinds of infrastructure_*, with a focus to managing three key properties: *Safety, Effectiveness and Security*. +Thus the "Safety, Effectiveness and Security - Requirements and Considerations" sections in this standard are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use. + +Note that specific requirements from the above mentioned standards, may also be captured in <>. +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 + + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 1:10 for SDPi- would have a summary here as 1:2.3.10). No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion in 1:2.3.1 below. + +In this version, the content is added as 1:2.3.1, and then the profiles as 1:2.3.10 to 1:2.3.13. Though the content is valid, it may be repositioned in subsequent versions to better integrate with the IHE DEV TF at a future date. + +*_Omitted from this version are profile-specific option summaries_* (e.g., 3.10.1?). It is unclear where to best place this content, and they are listed explicitly in each profile's detailed specification. + +|=== + +[#vol1_clause_sdpi_integration_profiles_overview] +==== Service-oriented Device Point-of-care Interoperability (SDPi) + + +[#vol1_clause_sdpi_scope] +===== SDPi Profiles – Scope of Application + +The Service-oriented Device Point-of-care Interoperability (SDPi) Profile specifications provide detailed instructions for seamless plug-and-play interoperability between IEEE 11073 SDC-based medical devices (including SaMD), as well as between medical devices and health IT systems based on HL7 FHIR and HL7 Version 2. +Key considerations include enabling safe, secure and effective interoperability for data reporting, alert notification, device-external control and other high-acuity point-of-care use cases. +Provision is made for coordination of individual device functional contributions to support clinical system functions that are provided by two or more participants. + + +Notes: + +1. High-acuity points of care include operating rooms (OR), intensive care units (ICU), step-down units, and emergency care. +2. Clinical system function example: Physiological monitoring of a patient's condition as they are being weaned off of a ventilator. +3. "SaMD" is Software as a Medical Device, including "clinical apps"; they are a class of health software. +4. IEEE 11073 Service-oriented Device Connectivity (SDC) standards provide a Services Oriented Architecture (SOA) specification for safe, effective and secure medical device interoperability (SES MDI). + + +[#vol1_clause_sdpi_overview_framework] +===== SDPi Profiles – Overview & Framework + +The 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] +image::../images/vol1-diagram-sdpi-profiles.svg[align=center] + +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? __* + +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. +This is achieved by the use of IHE "grouped actors". +Or IHE "gateway" actors include mappings to the foundational, non-SDC standards. + +The above figure illustrates how this balance was achieved, including: + +[none] +. *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* +[none] +.. The Profiles are built upon a solid foundation of existing standards from various <>s. Such standards 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 <>. +. *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. +.. The separation of interoperability purposes across four aspects both simplifies the complexity of each functional area, as well as implementation optionality, where some systems may only need to support connectivity and reporting but not alerting nor external control. +.. 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 four Profiles, which together provide a practical, pragmatic way toward genuine <> interoperability: + +[none] +. P -> SDPi-Plug-and-trust +. R -> SDPi-Reporting +. A -> SDPi-Alerting +. 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. +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 *_SOA & SOMDS Architecture Alignment_* in the Overview - Concepts section of the <> 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. +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_. +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. +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_*. +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. +Profile options are provided for additional capabilities that may be required to support extended scenarios. + +[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 2026). + +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). + +//// +#TODO: Add "alert delegation" to the Glossary and reference here# +//// + +[sdpi_offset=13] +==== Service-oriented Device Point-of-care Interoperability - External Control (SDPi-xC) Profile + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: 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 SDPi {ihe_supplement_sdpi_revision_short}_* and even basic controls will not be added until SDPi 3.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_*. +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 2027). + + +[sdpi_offset=5] +=== Dependencies between Integration Profiles + +[%noheader] +[cols="1"] +|=== +| Add the following dependencies below to the IHE DEV TF Profile Dependencies table. +|=== + +//// +#TODO: SHOULD ATNA BE ADDED TO THIS TABLE FOR SOMDS_PARTICIPANT?# +//// + +[#vol1_table_devices_integration_profile_dependencies] +.Devices Integration Profile Dependencies + +[%autowidth] +[cols="1,1,1,1"] +|=== +.^|Integration Profile +.^|Depends on +.^|Dependency Type +.^|Purpose + +| <> +| Consistent Time (CT) +| Each <> actor implementation (i.e., <>) shall be grouped with the CT Time Client Actor. Note: All <> actors are also grouped with the <> Actor. +| Required for consistent time-stamping of transactions and data. + +| <> +| Device Enterprise Communication (DEC)) +| The <> integrates DEC Device Observation Reporter (DOR) Actor specifications. +| 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 <> and <> to HL7 V2 and ACM transactions. + +|=== + +//// +#TODO: DO WE NEED TO ALSO MENTION DOC IN AN SDPI 1.X NOTE? WHAT ABOUT DEPENDENCY ON THE IHE DEV TF-2 APPENDIX A V2 GENERAL PROVISIONS?# +//// diff --git a/asciidoc/supplement/sdpi-supplement-tf1.adoc b/asciidoc/supplement/sdpi-supplement-tf1.adoc new file mode 100644 index 00000000..bcef7d01 --- /dev/null +++ b/asciidoc/supplement/sdpi-supplement-tf1.adoc @@ -0,0 +1,224 @@ +[#vol1_clause_profiles, sdpi_volume_caption=1] += Volume 1 -- Profiles + +// == Profiles + +// 2. +include::sdpi-supplement-tf1-ch-2-overview.adoc[] + +// 10. +// = Service-oriented Device Point-of-care Interoperability – Plug-and-trust (SDPi-P) Profile + +[#vol1_clause_sdpi_p_profile,sdpi_offset=10,role=profile,profile-id=sdpi-p,reftext="Plug-and-trust Profile",oid-arcs=.11] +== 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 #LINK PROBLEM# vol1_clause_sdpi_overview_framework + +//<>. + +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: <>. + +NOTE: #Add reference to the standard document for complete content# + +// 11. +// = Service-oriented Device Point-of-care Interoperability - Reporting (SDPi-R) Profile + +[#vol1_clause_sdpi_r_profile,sdpi_offset=11,role=profile,profile-id=sdpi-r,reftext="Reporting Profile",oid-arcs=.12] +== Service-oriented Device Point-of-care Interoperability – Reporting (SDPi-R) Profile + + +[#vol1_clause_sdpi_r_profile_reftext,reftext="SDPi-R Profile"] +The SDPi-Reporting ([[acronym_sdpi_r,SDPi-R]] SDPi-R) Profile supports the communication of information from one <> to other <> systems or to other external non-<> systems utilizing a <>. +Most of the actors and transactions in this specification are specialized versions of their counterparts in the <> Profile; however, are differentiated in that they are specifically designed to communicate information with an _intended medical purpose_. +As a result, additional requirements are added to each actor and transaction to support address these additional safety and effectiveness requirements (See _SDPi-R Safety, Effectiveness and Security - Requirements and Considerations_ below). + +NOTE: #Add reference to the standard document for complete content# + +// 12. +// = Service-oriented Device Point-of-care Interoperability – Alerting (SDPi-A) Profile + +[#vol1_clause_sdpi_a_profile,sdpi_offset=12,role=profile,profile-id=sdpi-a,reftext="Alerting Profile",oid-arcs=.13] +== Service-oriented Device Point-of-care Interoperability – Alerting (SDPi-A) Profile + + +[#vol1_clause_sdpi_a_profile_reftext,reftext="SDPi-A Profile"] +The SDPi-Alerting ([[acronym_sdpi_a,SDPi-A]] SDPi-A) Profile supports the communication of alert information from one <> to other <> systems or to other external non-<> systems utilizing a <>. +The actors and transactions in this specification are specialized versions of their counterparts in the <>; however, are differentiated in that they are specifically designed to communicate alert information to fulfill an _intended medical purpose_, primarily to notify a clinician of a patient or device-related condition that requires their attention. +Additional services have been provided to specifically support the exchange and management of this medical device alert information, providing a high-level of reliability and performance, commensurate with the potential risk to the patient if they are not promptly addressed. + +NOTE: #Add reference to the standard document for complete content# + +// 13. +// = Service-oriented Device Point-of-care Interoperability – external Control (SDPi-xC) Profile + +[#vol1_clause_sdpi_xc_profile,sdpi_offset=13,role=profile,profile-id=sdpi-xc,reftext="External Control Profile",oid-arcs=.14] +== Service-oriented Device Point-of-care Interoperability – external Control (SDPi-xC) Profile + +NOTE: #Add reference to the standard document for complete content# + +[#vol1_clause_sdpi_xc_profile_reftext,reftext="SDPi-xC Profile"] +The SDPi-External Control ([[acronym_sdpi_xc,SDPi-xC]] SDPi-xC) Profile enables external or "remote" control of one device by another, both being in the same secure environment (<>). +This may be as simple as adjust an alarm limit or triggering a blood pressure cuff reading, to adjusting a respiration rate on a ventilator or titrating a drug dose rate on an infusion pump. +Specializes services and semantics are provided to enable safe and secure control invocation. + +// TF-1 Appendix A +[appendix#vol1_appendix_a_requirements_management_for_p_n_t_interperability,sdpi_offset=A] +== Requirements Management for Plug-and-Trust Interoperability + +NOTE: #Add Appendix A Overview here w/ reference to Standard section# + +// A.1 +[#vol1_clause_appendix_a_requirements_from_narratives_to_pnt_interfaces,sdpi_offset=1] +=== Requirements: From Narratives to Plug-and-Trust Interfaces + +// A.2 +[#vol1_appendix_a_integrating_ses] +=== Integrating Safety, Effectiveness and Security Requirements and Considerations + +// A.3 +[#vol1_clause_appendix_a_ses_considerations_section_template] +=== SES Considerations Section Template + +// A.4 +[#vol1_clause_sdpi_requirements_modeling_integration] +=== SDPi Requirements Modeling & Integration + +// A.5 +[#vol1_clause_sdpi_requirement_future_extensibility] +=== Future extensibility: Use Cases, MBSE Requirements Modeling & SysML 2.0 + + +// Appendix B +[appendix#vol1_appendix_b_references,sdpi_offset=B] +== References + +// Appendix B +[bibliography#vol1_appendix_b_referenced_standards] +=== Referenced Standards + +NOTE: #Should this section be duplicated here to ensure that it is in the supplemenbt and eventually in the IHE DEV TF?# + +[%noheader] +[%autowidth] +[cols="1"] +|=== +| *{supplement_note}*: The standards listed in this section are predominantly published. +However, in the current version, three of them are unpublished drafts and are hence subject to requirement changes once they are published: <>, <> and <>. +No content from those three standards - including their requirements - is normatively used in the current version. +|=== + +* [[[ref_aami_2700_1_2019,AAMI 2700-1:2019]]] AAMI 2700-1:2019 Medical Devices And Medical Systems - Essential Safety And Performance Requirements For Equipment Comprising The Patient-Centric Integrated Clinical Environment (ICE) - Part 1: General Requirements And Conceptual Model, available at https://webstore.ansi.org/Standards/AAMI/ansiaami27002019. + +* [[[ref_hl7_fhir,HL7 FHIR]]] HL7^®^ Fast Healthcare Interoperability Resources (FHIR^®^), available at http://hl7.org/fhir/[hl7.org/fhir/]. + +* [[[ref_hl7_fhir_pocd_ig,HL7 FHIR Point-of-Care Device Implementation Guide]]] HL7 FHIR Point-of-Care Device Implementation Guide, drafts available at https://confluence.hl7.org/display/DOF/Devices+On+FHIR and (continuous build version) at https://build.fhir.org/ig/HL7/uv-pocd/. + +* [[[ref_hl7_v2,HL7 V2]]] HL7^®^ Version 2 (V2), available at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185. + +* [[[ref_iec_60601_1_8_2020,IEC 60601-1-8:2020]]] IEC 60601-1-8:2006/AMD2:2020, Medical electrical equipment — Part 1-8: General requirements for basic safety and essential performance — Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems; Amendment 1:2020, and Amendment 2:2020, available at https://webstore.iec.ch/publication/59648 and https://www.iso.org/standard/41986.html. + +* [[[ref_iec_60601_2_27_2011,IEC 60601-2-27:2011]]] IEC 60601-2-27:2011, Medical electrical equipment — Part 2-27: Particular requirements for the basic safety and essential performance of electrocardiographic monitoring equipment, available at https://webstore.iec.ch/en/publication/2638. + +* [[[ref_ieee_11073_10101_2020,IEEE 11073-10101:2020]]] IEEE 11073-10101™ International Standard - Health informatics--Device interoperability--Part 10101:Point-of-care medical device communication--Nomenclature, available at https://standards.ieee.org/ieee/11073-10101/10343/. + +* [[[ref_ieee_11073_10201_2004,IEEE 11073-10201:2004]]] IEEE 11073-10201™ International Standard - Health informatics--Device interoperability--Part 10201:Point-of-care medical device communication--Domain information model. Note this was updated in 2020. Available at https://standards.ieee.org/ieee/11073-10201/10263/. + +* [[[ref_ieee_11073_10207_2017,IEEE 11073-10207:2017]]] IEEE 11073-10207-2017, Health informatics — Point-of-care medical device communication — Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication, 2017-12, available at https://standards.ieee.org/ieee/11073-10207/6032 footnote:ieee_permission[]. + +* [[[ref_ieee_11073_10700_2022,IEEE 11073-10700:2022]]] IEEE 11073-10700™ IEEE Standard -- Health Informatics--Device Interoperability Part 10700: Point‐of‐Care Medical Device Communication--Standard for Base Requirements for Participants in a Service‐Oriented Device Connectivity (SDC) System, available at https://standards.ieee.org/ieee/11073-10700/10630/. + +* [[[ref_ieee_11073_10701_2022,IEEE 11073-10701:2022]]] IEEE 11073-10701™ IEEE Standard for Health Informatics - Device Interoperability - Part 10701: Point-of-Care Medical Device Communication - Metric Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System, available at https://standards.ieee.org/ieee/11073-10701/7538/. + +* [[[ref_ieee_11073_10702_202x,IEEE 11073-10702:202x]]] IEEE P11073-10702™/D1 Draft Standard for Health Informatics – Device Interoperability – Part 10702: Point-of-Care Medical Device Communication – Alert Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System, in development. + +* [[[ref_ieee_11073_10703_202x,IEEE 11073-10703:202x]]] IEEE P11073-10703™/Draft Standard for Health Informatics – Device Interoperability – Part 10703: Point-of-Care Medical Device Communication – External Control by Participants in a Service-Oriented Device Connectivity (SDC) System, in development. + +* [[[ref_ieee_11073_20701_2018,IEEE 11073-20701:2018]]] IEEE 11073-20701-2018, Health informatics — Point-of-care medical device communication — Part 20701: Service-Oriented Medical Device Exchange Architecture and Protocol Binding, 2018-09, available at https://standards.ieee.org/ieee/11073-20701/6059. + +* [[[ref_ieee_11073_20702_2016,IEEE 11073-20702:2016]]] IEEE 11073-20702-2016, Health informatics — Point-of-care medical device communication — Part 20702: Medical Devices Communication Profile for Web Services, 2016-09, available at https://standards.ieee.org/ieee/11073-20702/6034 + +* [[[ref_iec_80001_1_2021,IEC 80001-1:2021]]] IEC 80001-1:2021 Application of risk management for IT-networks incorporating medical devices — Part 1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software, available at https://webstore.iec.ch/publication/34263 and https://www.iso.org/standard/72026.html. + +* [[[ref_iso_81001_1_2021,ISO/IEC 81001-1:2021]]] ISO 81001-1:2021 Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts, available at https://www.iso.org/standard/71538.html and https://webstore.iec.ch/publication/34286. + +* [[[ref_ihe_dev_tf_1_2024,IHE DEV TF-1:2024]]] IHE Devices Technical Framework, Vol. 1, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_DEV_TF_Vol1.pdf. + +* [[[ref_ihe_dev_tf_2_2024,IHE DEV TF-2:2024]]] IHE Devices Technical Framework, Vol. 2, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_DEV_TF_Vol2.pdf. + +* [[[ref_ihe_dev_tf_3_2024,IHE DEV TF-3:2024]]] IHE Devices Technical Framework, Vol. 3, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_DEV_TF_Vol3.pdf. + +* [[[ref_rfc_3986, RFC 3986]]] T. Berners-Lee et al., RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005, available at https://www.rfc-editor.org/rfc/rfc3986 + +* [[[ref_rfc_5905, RFC 5905]]] D. Mills et al., RFC 5905, Network Time Protocol Version 4: Protocol And Algorithms Specification, June 2010, available at https://www.rfc-editor.org/rfc/rfc5905 + +* [[[ref_rfc_6585, RFC 6585]]] M. Nottingham, R. Fielding, RFC 6585, Additional HTTP Status Codes, April 2012, available at https://www.rfc-editor.org/rfc/rfc6585 + +* [[[ref_rfc_7231, RFC 7231]]] R. Fielding, J. Reschke, RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, June 2014, available at https://www.rfc-editor.org/rfc/rfc7231 + +* [[[ref_rfc_9110, RFC 9110]]] R. Fielding, M. Nottingham, J. Reschke, RFC 9110, HTTP Semantics, June 2022, available at https://www.rfc-editor.org/rfc/rfc9110 + +* [[[ref_oasis_dpws_2009,OASIS DPWS:2009]]] OASIS Standard, Devices Profile for Web Services Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html + +* [[[ref_oasis_soap_over_udp_v1_1, OASIS SOAP-over-UDP Version 1.1]]] OASIS Standard, SOAP-over-UDP Version 1.1, July 2009, available at http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.docx. + +* [[[ref_w3c_soap_over_http_v1_2, SOAP Version 1.2 Part 0]]] SOAP Version 1.2 Part 0: Primer (second edition), W3C Recommendation 27 April 2007, available at https://www.w3.org/TR/soap12-part0/. + +* [[[ref_oasis_ws_addressing_2006,W3C Recommendation, WS-Addressing:2006]]] Web Services Addressing 1.0 - Core (WS-Eventing), W3C Recommendation 9 May 2006, available at https://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. + +* [[[ref_oasis_ws_discovery_2009,OASIS WS-Discovery:2009]]] OASIS Standard, Web Services Dynamic Discovery (WS-Discovery) Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html. + +* [[[ref_w3c_ws_eventing_2006,W3C Submission, WS-Eventing:2006]]] W3C Web Services Eventing (WS-Eventing), W3C Member Submission 15 March 2006, available at https://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/. + +* [[[ref_w3c_ws_metadata_exchange_2008,W3C Submission, WS-MetadataExchange:2008]]] Web Services Metadata Exchange 1.1 (WS-MetadataExchange), W3C Member Submission 13 August 2008, available at https://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/. + +* [[[ref_wc3_ws_transfer_2006,WC3 Standard, WS-Transfer:2006]]] WC3 Web Services Transfer (WS-Transfer), W3C Standard, 27 September 2006, available at https://www.w3.org/Submission/WS-Transfer/. + +// Appendix B.x +[#vol1_appendix_b_referenced_standards_conformance] +=== Referenced Standards Conformance + + +[bibliography] +==== Standards & Publications + +The following bibliographic references include standards that are related to this specification but do not contain normative requirements, as well as papers that are useful in understanding related concepts. + +* [[[ref_ihe_pcd_sdpi_use_cases_compendium_2019,IHE PCD SDPi Use Cases Compendium:2019]]] IHE Patient Care Devices (PCD) Compendium of Medical Device Oriented Use Cases, Companion to the "Service-oriented Device Point-of-Care Interoperability (SDPi)" White Paper, Revision 1.1, November 1, 2019. Available at https://profiles.ihe.net/DEV/[profiles.ihe.net/DEV/]. + +* [[[ref_ihe_pcd_sdpi_white_paper_2019,IHE PCD SDPi White Paper:2019]]] IHE Patient Care Devices (PCD) Service-oriented Device Point-of-Care Interoperability (SDPi) White Paper, Revision 1.1, November 1, 2019. Available at https://profiles.ihe.net/DEV/[profiles.ihe.net/DEV/]. + +* [[[ref_iso_iec_14977_1996, ISO/IEC 14977:1996]]] ISO/IEC 14977, Information technology - Syntactic +metalanguage - Extended BNF, 15 December 1996, available at https://standards.iso.org/ittf/PubliclyAvailableStandards/s026153_ISO_IEC_14977_1996(E).zip + +* [[[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 + +The following bibliographic references include slide decks and recordings that are helpful in understanding these specifications. + +* [[[ref_ihe_eu_experience_2021_presentation_cooper_schlichting,IHE EU Experience-2021 IHE CA for MedTech Solutions]]] "IHE & IHE Catalyst: Advancing Interoperable MedTec Solutions with "Regulatory Submission Ready" Conformity Assessment", presentation by Todd Cooper and Dr. Stefan Schlichting, available at https://connectathon.ihe-europe.net/experience-sessions-2021-presentations[IHE Europe Experience 2021 Presentations web page]. + + +// Appendix C +// = Device Point-of-care Interoperability (DPI) Use Cases + +[appendix#vol1_appendix_c_dpi_use_cases,sdpi_offset=C] +== Device Point-of-care Interoperability (DPI) Use Cases + + + diff --git a/asciidoc/supplement/sdpi-supplement-tf2.adoc b/asciidoc/supplement/sdpi-supplement-tf2.adoc new file mode 100644 index 00000000..e9d38648 --- /dev/null +++ b/asciidoc/supplement/sdpi-supplement-tf2.adoc @@ -0,0 +1,193 @@ +[#vol2, sdpi_volume_caption=2] += Volume 2 -- Transactions + +[#vol2_clause_transactions,sdpi_offset=3] +== Transactions + +NOTE: #Need to determine whether to stub out each transaction or simply add a note pointing to the standard# + +//// + +// Announce Network Presence +include::dev-23/tf2-dev-23.adoc[] + +// Discover Network Topology [DEV-24] +include::dev-24/tf2-dev-24.adoc[] + +// Discover BICEPS Services [DEV-25] +include::dev-25/tf2-dev-25.adoc[] + +//=== Discover System Context and Capabilities [DEV-26] + +// Manage BICEPS Subscription [DEV-27] +include::dev-27/tf2-dev-27.adoc[] + +//=== Notify Change in System Context and Capabilities [DEV-28] +include::dev-28/tf2-dev-28.adoc[] + +//=== Publish BICEPS Update Reports [DEV-29] +include::dev-29/tf2-dev-29.adoc[] + +//=== Retrieve BICEPS Content [DEV-30] +include::dev-30/tf2-dev-30.adoc[] + +//=== Retrieve Archive Data [DEV-32] +include::dev-32/tf2-dev-32.adoc[] + +//=== Retrieve Localization Information [DEV-33] +include::dev-33/tf2-dev-33.adoc[] + +//=== Announce Network Departure [DEV-34] +include::dev-34/tf2-dev-34.adoc[] + +//=== Establish Medical Data Exchange [DEV-35] +include::dev-35/tf2-dev-35.adoc[] + +//=== Publish Medical Data [DEV-36] +include::dev-36/tf2-dev-36.adoc[] + +//=== Retrieve Medical Data [DEV-37] +include::dev-37/tf2-dev-37.adoc[] + +//=== Establish Medical Alert Exchange [DEV-38] +include::dev-38/tf2-dev-38.adoc[] + +//=== Publish Medical Alert Update [DEV-39] +include::dev-39/tf2-dev-39.adoc[] + +//=== Retrieve Medical Alert Status [DEV-40] +include::dev-40/tf2-dev-40.adoc[] + +//=== Update Network Presence [DEV-46] +include::dev-46/tf2-dev-46.adoc[] + +//=== Retrieve Network Presence [DEV-47] +include::dev-47/tf2-dev-47.adoc[] + +//=== Establish Distributed Alarm System [DEV-48] +include::dev-48/tf2-dev-48.adoc[] + +//=== End Distributed Alarm System [DEV-49] +include::dev-49/tf2-dev-49.adoc[] + +// TODO how does this differ from DEV-30 +// +//[appendix#clause-mdpws-constraints-corrigenda-adjuncts] +//== MDPWS Constraints, Corrigenda & Adjuncts +// +//=== Handling missed discovery messages +// +// TODO https://confluence.hl7.org/display/GP/Topic%3A+Handling+missed+discovery+messages +// +//=== Compression Option +// +// TODO https://confluence.hl7.org/display/GP/Topic%3A+SDPi-P+Compression+Option +// +//=== WS-Eventing +// +//=== Subscription / Subscription Manager Identifier +// +// TODO finding from PAT: no use of wse:identifier, use path dispatching; see https://confluence.hl7.org/pages/viewpage.action?pageId=104579763 +// +//=== SubscribeResponse Outline and XML Schema Conflict +// +// TODO finding from PAT: no use of infinite subscriptions; see https://confluence.hl7.org/pages/viewpage.action?pageId=131051997 +// +//=== Use of SubscriptionManager Addresses for Renew and Unsubscribe +// +// TODO finding from PAT: requirement is should, make it mandatory; see https://confluence.hl7.org/pages/viewpage.action?pageId=131051997 +// +//[appendix#clause-biceps-constraints-corrigenda-adjuncts] +//== BICEPS Constraints, Corrigenda & Adjuncts +// +//=== SystemContext Profiling & Use +// +// TODO https://confluence.hl7.org/pages/viewpage.action?pageId=86970701 +// +//=== Profiling BICEPS Services in SDPi-P +// +// no TOI contents available yet +// +//=== MDIB Version Update Guidelines +// +// no TOI contents available yet +// +//[appendix#clause-sdc-glue-constraints-corrigenda-adjuncts] +//== SDC Glue Constraints, Corrigenda & Adjuncts +// +//=== Info exchanged during unsecured discovery +// +// TODO https://confluence.hl7.org/display/GP/Topic%3A+Info+exchanged+during+unsecured+discovery +// +//=== Connect Time Delay Algorithm +// +// TODO https://confluence.hl7.org/display/GP/Topic%3A+Connect+Time+Delay+Algorithm +// + +//NOTE: This document integrates all the content that makes up the standard volume 2 document. +// +//IMPORTANT: Migrate the content below from main.adoc into this document OR rename main.adoc to this ... though the content is different. + +//{empty} + +//*_See the Word document for what this is supposed to look like_*. + +//// + +[appendix#vol2_appendix_a_mdpws_messages,sdpi_offset=A,role="protocol",protocol-id=mdpws] +== IEEE 11073 SDC / MDPWS Message Specifications (Normative) + +NOTE: #Add a summary of TF-2A here# + +=== Service Mapping + +=== Message Mapping + +=== Security Considerations + +[appendix#vol2_appendix_b_gateways,sdpi_offset=B] +== Gateways (Normative) + +[sdpi_offset=1] +=== Overview SDC Gateways +Although the primary focus of the SDPi profiles is to enable device-to-device, plug-and-trust interoperability between provider and consumer systems on an SDC network, many potential applications also require integration with external systems that utilize protocols other than SDC. These applications include healthcare enterprise integration using other widely deployed specifications, such as the IHE DEV PCD profiles that leverage HL7 V2 messaging with IEEE 11073 semantic content, or access to lab and patient demographic information. The gateways defined in this appendix establish a consistent means for integrating SDC-enabled systems with systems that utilize other protocols and profile specifications. + +[#vol2_clause_appendix_sdpi_gateway_hl7_v2_general_mapping,role=gateway,gateway-id=hl7v2] +=== SDPi Gateway -- HL7 V2 General Mapping +This section specifies general <> V2 requirements and mappings, which apply to the <> as well as to the <> sections below. + +[#vol2_clause_appendix_sdpi_dec_gateway,role=gateway,gateway-id=dec] +=== 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 <>. + +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. + +[#vol2_clause_appendix_sdpi_acm_gateway,role=gateway,gateway-id=acm] +=== 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 <>. + +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. + +[#vol2_clause_appendix_sdpi_fhir_gateway,role=gateway,gateway-id=fhir] +=== 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. + + + +[appendix#vol2_appendix_c_security_management,sdpi_offset=C] +== Security Management (Normative) + + + + diff --git a/asciidoc/supplement/sdpi-supplement-tf3.adoc b/asciidoc/supplement/sdpi-supplement-tf3.adoc new file mode 100644 index 00000000..d7f58b3b --- /dev/null +++ b/asciidoc/supplement/sdpi-supplement-tf3.adoc @@ -0,0 +1,238 @@ + +[#vol3, sdpi_volume_caption=3] += Volume 3 -- Content Modules + +[#clause-content-modules] + +// == Content Modules + +NOTE: #Volume 3 has a significant number of supplement instructions that need to be migrated FROM the standard to this supplement + +// 8 +[#vol3_clause_content_modules,sdpi_offset=8] +== DEV Semantic Content Modules + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: The organization of this Volume 3 standard factors in two major changes: + +// STANDALONE TO DO ... this section + + +. IHE Supplement template (2020), with content mapped from the <> specification; + +. Addition of <> content to a volume that is organized according to the "classic" <> domain information model (DIM). + +For this version of the standard, content from the 2024 version that was in sections 3 and 7 has now been collected into a single Section 8. + +In order to clearly identify the standard content that is related to <>, specific sections with <> in the title have been added. +Although this results in a fairly clean standard 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 standard 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 standard or will be accomplished through a specific Change Proposal (CP) to the published IHE DEV TF-3._* + +Additionally, for this version of SDPi, it isn't clear how best to address a similar division of the device specialization sections (e.g., infusion pump or ventilator). +Version note boxes (like this one) have therefore been added to the specializations section and a single BICEPS subsection has been added. +Subsequent versions of the specification may address this more comprehensively. + +*REVIEWER QUESTION*: Please consider not only the <>-related updates but also the changes to the general organization and provide guidance as to whether this TF-3 is better organized for clarity and future extensions, or if a different approach should be taken. + +|=== + + +// 8.1 +[sdpi_offset=1] +=== Overview of device semantic content + +[%noheader] +[cols="1"] +|=== +| Move IHE DEV 2024 TF-3 Section 3 (text immediately after the section header) to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.1 +|=== + +//// +#TODO: Update the IHE DEV 2024 TF-3 Section 3 content to be model/format independent# +//// + +// 8.2 +=== General device content considerations + +[%noheader] +[cols="1"] +|=== +| Move IHE DEV 2024 TF-3 sections 3.1 to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.2 +|=== + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: The content in the IHE DEV 2024 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. +|=== + + +// 8.3 +[#vol3_clause_protocol_specific_content_module_considerations] + +=== Protocol-Specific Content Module Considerations +NOTE: #Provide Standard Section Reference language here# + +// 8.3.1 +[#vol3_clause_ieee_11073_10201_classic_dim_content_modules] +==== IEEE 11073-10201 Classic DIM Content Modules + +[%noheader] +[cols="1"] +|=== +| Move IHE DEV 2024 TF-3 sections 3.2 to 3.7 to this SDPi {ihe_supplement_sdpi_revision_short} 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 (2024) Section 3.1, where that content is specific to the Classic DIM (see related note above). +|=== + +// 8.3.2 +[#vol3_clause_sdc_biceps_semantic_content] +[role=content-module,content-module-id=biceps,oid-arcs=".1"] +==== IEEE 11073-10207 BICEPS Content Modules + +// 8.3.2.1 +[#vol3_clause_sdc_biceps_semantic_content_module] +===== SDC/BICEPS Content Module + + +// 3:8.3.2.6 +[#vol3_clause_system_type_nomenclature_extensions] +===== System Type Nomenclature Extensions +In addition to specific device specializations (see <> below), SDPi specifications, especially TF-1 use cases, refer to a number of general classes or types of systems. +These systems provide common services to all other <>'s; however, in order to be discovered on the network, they must have system type identifiers that can be recognized by these other systems (explicitly / implicitly). + +NOTE: #This section is only included due to a reference from the Glossary for Central Station. QUESTION: Should that glossary reference be generalized without a hard reference link?# + + +// 8.3.3 +==== RESERVED + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: This is a place holder section for content modules related to the Personal Health Device (PHD) semantics defined in the IEEE 11073-10206 and 11073-20601 standards. +Though there are no PHD requirements in this standard, there are PHD profiles that may be integrated into the IHE DEV Technical Framework, and as a result may add content to this section. +|=== + +// 8.4 8.5 8.6 RESERVED +=== RESERVED + +[%noheader] +[cols="1"] +|=== +| Move IHE DEV 2024 TF-3 Section 4 Reserved to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.4 +|=== + +=== RESERVED + +[%noheader] +[cols="1"] +|=== +| Move IHE DEV 2024 TF-3 Section 5 Reserved to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.5 +|=== + +=== RESERVED + +[%noheader] +[cols="1"] +|=== +| Move IHE DEV 2024 TF-3 Section 6 Reserved to this {ihe_supplement_sdpi_revision_short} TF-3 Section 8.6 +|=== + +// 8.7 +[#vol3_clause_device_specialization_content_modules,sdpi_offset=7] +=== Device specialization content modules + +// Appendix A BICEPS Extension Provisions SML Schemas +[appendix#vol3_appendix_a_xml_schemas,sdpi_offset=A] +== BICEPS Extension Provisions XML Schemas + +XML Schemas in this appendix include the BICEPS message, participant and extension Model files as provided as an additional resource at https://standards.ieee.org/ieee/11073-10207/6032/. + +// Appendix B BICEPS Extension Namespace +[appendix#vol3_appendix_b_biceps_extension_namespace,sdpi_offset=B] +== BICEPS Extension Namespace + +Extensions to the BICEPS Participant and Message Model defined in this specification utilize the XML Schema target namespace URI `urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1`, of which the OID is further detailed in <> and <>. + +[#vol3_table_sdpi_biceps_extension_namespace] +.SDPi BICEPS Extension Namespace OID Assignment +[cols="2,3,1",options="autowidth, header"] +|=== +| Primary identifier +| Concept description +| Secondary identifier + +| `{SDPi-parent-oid}` +| Profile specific OID for SDPi +| sdpi + +| `{SDPi-parent-oid}.*1*` +| Describes namespaces for different purposes as specified by its sub-nodes +| namespaces + +| `{SDPi-parent-oid}.*1.1*` +| Extensions to the BICEPS Participant and Message Model +| biceps-extensions + +| `{SDPi-parent-oid}.*1.1.1*` +| Major version 1 for extensions to the BICEPS Participant and Message Model. +In order to avoid proliferation of OIDs below `{SDPi-parent-oid}.1.1`, versions are incremented only if incompatible changes are made to an extension. +| version1 + +|=== + +// Appendix C OID identifiers +[appendix#vol3_appendix_c_oids,sdpi_offset=C] +== OID identifiers + +Object identifiers, or OIDs, are globally unique numeric identifiers used to name something in a formal, unambiguous way. +They are typically formatted as dotted number strings (`1.3.6.1.4.1.19376.1.6`, for example). Each number (or _arc_) is a node in a +hierarchical, tree-structured, namespace. The top of the tree, and first arc in the sequence, is managed by standards +bodies who delegate responsibility for distinct branches in the hierarchy. + +IHE DEV is responsible for managing arcs from the _IHE DEV parent_ OID `1.3.6.1.4.1.19376.1.6`. +See https://wiki.ihe.net/index.php/PCD_OID_Management[PCD OID Management]. +They have designated `{SDPi-parent-oid}` as the parent OID for a hierarchy of object identifiers for this +service-oriented device point-of-care interoperability (SDPi) specification. + +This standard is responsible for the hierarchy underneath the `{SDPi-parent-oid}` SDPi top level oid. + +Generally, the meaning of OIDs should not change once assigned. For example, `{SDPi-parent-oid}.3.40` will always refer to a +<>. This OID will never be assigned another meaning even if, for some reason, a SOMDS participant is no longer +relevant to the specification. + +// Appendix Z Implementation conformity statements +[appendix#vol3_appendix_z_ics,sdpi_offset=Z] +== Implementation conformity statements + +=== General format + +Implementation conformity statements take the form of tables. Templates for these _ICS tables_ +are given in <>. The tables are completed and provided as an overall conformity +statement document. + + +[#vol3_ics_tables] +=== Tables + + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: This section includes ICS tables that have been generated from requirements in the preceding content of this standard. Tables are generated for each of the SDPi actors, such as <> or <>, enabling a concise reference for answering the quesiton "What are the implementation requirements for a <>?", for example. +|=== + + diff --git a/asciidoc/volume0/tf0-ch-9-copyrights.adoc b/asciidoc/supplement/volume0/tf0-ch-9-copyrights.adoc similarity index 94% rename from asciidoc/volume0/tf0-ch-9-copyrights.adoc rename to asciidoc/supplement/volume0/tf0-ch-9-copyrights.adoc index e37c8eda..77983063 100644 --- a/asciidoc/volume0/tf0-ch-9-copyrights.adoc +++ b/asciidoc/supplement/volume0/tf0-ch-9-copyrights.adoc @@ -18,9 +18,9 @@ IHE technical documents refer to, and make use of, a number of standards develop [cols="1"] |=== a| *{supplement_note}*: The content below is verbatim from the IEEE permission letter. -An abbreviated version may be provided in subsequent supplement versions with a reference to the complete letter. +An abbreviated version may be provided in subsequent standard versions with a reference to the complete letter. -The copyright language will need to be updated to support future PKP standards <> and <>. +The copyright language will need to be updated to support future PKP standards #LINK OR TEXT#ref_ieee_11073_10702_202x and #LINK OR TEXT#ref_ieee_11073_10703_202x. Note that NIST and the RTTMS tools are a key factor in the nomenclature aspect of the licensing discussion. diff --git a/asciidoc/volume0/tf0-ch-a-actors.adoc b/asciidoc/supplement/volume0/tf0-ch-a-actors.adoc similarity index 100% rename from asciidoc/volume0/tf0-ch-a-actors.adoc rename to asciidoc/supplement/volume0/tf0-ch-a-actors.adoc diff --git a/asciidoc/volume0/tf0-ch-b-transactions.adoc b/asciidoc/supplement/volume0/tf0-ch-b-transactions.adoc similarity index 79% rename from asciidoc/volume0/tf0-ch-b-transactions.adoc rename to asciidoc/supplement/volume0/tf0-ch-b-transactions.adoc index 4899d124..8929a776 100644 --- a/asciidoc/volume0/tf0-ch-b-transactions.adoc +++ b/asciidoc/supplement/volume0/tf0-ch-b-transactions.adoc @@ -15,6 +15,8 @@ //// +// STANDALONE NOTE: Duplicated Transaction Summary files because those in the standard have references to specific standard-actor definition sections, that are not in the supplement + [cols="1,2,3"] |=== |New Transaction Number |New Transaction Name |Definition @@ -23,157 +25,164 @@ [[transaction_number_dev_23,DEV-23]] DEV-23 | [[transaction_name_announce_network_presence,Announce Network Presence]] Announce Network Presence | -include::../volume2/dev-23/tf2-dev-23-summary.adoc[] +include::transaction-summaries/tf2-dev-23-summary.adoc[] .^| [[vol0_transaction_summary_dev_24,DEV-24 Discover Network Topology]] [[transaction_number_dev_24,DEV-24]] DEV-24 | [[transaction_name_discover_network_topology,Discover Network Topology]] Discover Network Topology | -include::../volume2/dev-24/tf2-dev-24-summary.adoc[] +include::transaction-summaries/tf2-dev-24-summary.adoc[] .^| [[vol0_transaction_summary_dev_25,DEV-25 Discover BICEPS Services]] [[transaction_number_dev_25,DEV-25]] DEV-25 | [[transaction_name_discover_biceps_services,Discover BICEPS Services]] Discover BICEPS Services | -include::../volume2/dev-25/tf2-dev-25-summary.adoc[] +include::transaction-summaries/tf2-dev-25-summary.adoc[] .^| [[vol0_transaction_summary_dev_26,DEV-26 Discover System Context and Capabilities]] [[transaction_number_dev_26,DEV-26]] DEV-26 | [[transaction_name_discover_system_context_and_capabilities,Discover System Context and Capabilities]] Discover System Context and Capabilities | Deferred to a future version of SDPi -// include::../volume2/dev-26/tf2-dev-26-summary.adoc[] +// include::../../volume2/dev-26/tf2-dev-26-summary.adoc[] .^| [[vol0_transaction_summary_dev_27,DEV-27 Manage BICEPS Subscription]] [[transaction_number_dev_27,DEV-27]] DEV-27 | [[transaction_name_manage_biceps_subscription,Manage BICEPS Subscription]] Manage BICEPS Subscription | -include::../volume2/dev-27/tf2-dev-27-summary.adoc[] +include::transaction-summaries/tf2-dev-27-summary.adoc[] .^| [[vol0_transaction_summary_dev_28,DEV-28 Notify Change in System Context and Capabilities]] [[transaction_number_dev_28,DEV-28]] DEV-28 | [[transaction_name_notify_change_in_system_context_and_capabilities,Notify Change in System Context and Capabilities]] Notify Change in System Context and Capabilities | -include::../volume2/dev-28/tf2-dev-28-summary.adoc[] +include::transaction-summaries/tf2-dev-28-summary.adoc[] + .^| [[vol0_transaction_summary_dev_29,DEV-29 Publish BICEPS Update Reports]] DEV-29 | [[transaction_name_publish_biceps_update_reports,Publish BICEPS Update Reports]] Publish BICEPS Update Reports | -include::../volume2/dev-29/tf2-dev-29-summary.adoc[] +include::transaction-summaries/tf2-dev-29-summary.adoc[] .^| [[vol0_transaction_summary_dev_30,DEV-30 Retrieve BICEPS Content]] [[transaction_number_dev_30,DEV-30]] DEV-30 | [[transaction_name_retrieve_biceps_content,Retrieve BICEPS Content]] Retrieve BICEPS Content | -include::../volume2/dev-30/tf2-dev-30-summary.adoc[] +include::transaction-summaries/tf2-dev-30-summary.adoc[] + .^| [[vol0_transaction_summary_dev_31,DEV-31 Set Provider State]] [[transaction_number_dev_31,DEV-31]] DEV-31 | [[transaction_name_set_provider_state,Set Provider State]] Set Provider State | Deferred to a future version of SDPi -// include::../volume2/dev-31/tf2-dev-31-summary.adoc[] +// include::../../volume2/dev-31/tf2-dev-31-summary.adoc[] .^| [[vol0_transaction_summary_dev_32,DEV-32 Retrieve Archive Data]] [[transaction_number_dev_32,DEV-32]] DEV-32 | [[transaction_name_retrieve_archive_data,Retrieve Archive Data]] Retrieve Archive Data | -include::../volume2/dev-32/tf2-dev-32-summary.adoc[] +include::transaction-summaries/tf2-dev-32-summary.adoc[] + .^| [[vol0_transaction_summary_dev_33,DEV-33 Retrieve Localization Information]] [[transaction_number_dev_33,DEV-33]] DEV-33 | [[transaction_name_retrieve_localization_information,Retrieve Localization Information]] Retrieve Localization Information | -include::../volume2/dev-33/tf2-dev-33-summary.adoc[] +include::transaction-summaries/tf2-dev-33-summary.adoc[] //| [[vol0_transaction_summary_dev_34,DEV-34 Announce Network Departure]] DEV-34 //| [[transaction_name_announce_network_departure,Announce Network Departure]] Announce Network Departure //| -//include::../volume2/dev-34/tf2-dev-34-summary.adoc[] +// include::../../volume2/dev-34/tf2-dev-34-summary.adoc[] + .^| DEV-34 | _Reserved_ | -//include::../volume2/dev-34/tf2-dev-34-summary.adoc[] +// include::../../volume2/dev-34/tf2-dev-34-summary.adoc[] + .^| [[vol0_transaction_summary_dev_35,DEV-35 Establish Medical Data Exchange]] [[transaction_number_dev_35,DEV-35]] DEV-35 | [[transaction_name_establish_medical_data_exchange,Establish Medical Data Exchange]] Establish Medical Data Exchange | -include::../volume2/dev-35/tf2-dev-35-summary.adoc[] +include::transaction-summaries/tf2-dev-35-summary.adoc[] + .^| [[vol0_transaction_summary_dev_36,DEV-36 Publish Medical Data]] [[transaction_number_dev_36,DEV-36]] DEV-36 | [[transaction_name_publish_medical_data,Publish Medical Data]] Publish Medical Data | -include::../volume2/dev-36/tf2-dev-36-summary.adoc[] +include::transaction-summaries/tf2-dev-36-summary.adoc[] + .^| [[vol0_transaction_summary_dev_37,DEV-37 Retrieve Medical Data]] [[transaction_number_dev_37,DEV-37]] DEV-37 | [[transaction_name_retrieve_medical_data,Retrieve Medical Data]] Retrieve Medical Data | -include::../volume2/dev-37/tf2-dev-37-summary.adoc[] +include::transaction-summaries/tf2-dev-37-summary.adoc[] .^| [[vol0_transaction_summary_dev_38,DEV-38 Establish Medical Alert Exchange]] [[transaction_number_dev_38,DEV-38]] DEV-38 | [[transaction_name_establish_medical_alert_exchange,Establish Medical Alert Exchange]] Establish Medical Alert Exchange | -include::../volume2/dev-38/tf2-dev-38-summary.adoc[] +include::transaction-summaries/tf2-dev-38-summary.adoc[] .^| [[vol0_transaction_summary_dev_39,DEV-39 Publish Medical Alert Update]] [[transaction_number_dev_39,DEV-39]] DEV-39 | [[transaction_name_publish_medical_alert_update,Publish Medical Alert Update]] Publish Medical Alert Update | -include::../volume2/dev-39/tf2-dev-39-summary.adoc[] +include::transaction-summaries/tf2-dev-39-summary.adoc[] .^| [[vol0_transaction_summary_dev_40,DEV-40 Retrieve Medical Alert Status]] [[transaction_number_dev_40,DEV-40]] DEV-40 | [[transaction_name_retrieve_medical_alert_status,Retrieve Medical Alert Status]] Retrieve Medical Alert Status | -include::../volume2/dev-40/tf2-dev-40-summary.adoc[] +include::transaction-summaries/tf2-dev-40-summary.adoc[] .^| [[vol0_transaction_summary_dev_41,DEV-41 Manage Medical Alert Delegation]] [[transaction_number_dev_41,DEV-41]] DEV-41 | [[transaction_name_manage_medical_alert_delegation,Manage Medical Alert Delegation]] Manage Medical Alert Delegation | Deferred to a future version of SDPi -// include::../volume2/dev-41/tf2-dev-41-summary.adoc[] +// include::../../volume2/dev-41/tf2-dev-41-summary.adoc[] .^| [[vol0_transaction_summary_dev_42,DEV-42 Delegate Medical Alert]] [[transaction_number_dev_42,DEV-42]] DEV-42 | [[transaction_name_delegate_medical_alert,Delegate Medical Alert]] Delegate Medical Alert | Deferred to a future version of SDPi -// include::../volume2/dev-42/tf2-dev-42-summary.adoc[] +// include::../../volume2/dev-42/tf2-dev-42-summary.adoc[] .^| [[vol0_transaction_summary_dev_43,DEV-43 Update Alert Acknowledgement Status]] [[transaction_number_dev_43,DEV-43]] DEV-43 | [[transaction_name_update_alert_acknowledgement_status,Update Alert Acknowledgement Status]] Update Alert Acknowledgement Status | Deferred to a future version of SDPi -// include::../volume2/dev-43/tf2-dev-43-summary.adoc[] +// include::../../volume2/dev-43/tf2-dev-43-summary.adoc[] .^| [[vol0_transaction_summary_dev_44,DEV-44 Manage Medical External Control]] [[transaction_number_dev_44,DEV-44]] DEV-44 | [[transaction_name_manage_medical_external_control,Manage Medical External Control]] Manage Medical External Control | Deferred to a future version of SDPi -// include::../volume2/dev-44/tf2-dev-44-summary.adoc[] +// include::../../volume2/dev-44/tf2-dev-44-summary.adoc[] .^| [[vol0_transaction_summary_dev_45,DEV-45 Invoke Medical Control Services]] [[transaction_number_dev_45,DEV-45]] DEV-45 | [[transaction_name_invoke_medical_control_services,Invoke Medical Control Services]] Invoke Medical Control Services | Deferred to a future version of SDPi -// include::../volume2/dev-45/tf2-dev-45-summary.adoc[] +// include::../../volume2/dev-45/tf2-dev-45-summary.adoc[] .^| [[vol0_transaction_summary_dev_46,DEV-46 Update Network Presence]] [[transaction_number_dev_46,DEV-46]] DEV-46 | [[transaction_name_update_network_presence,Update Network Presence]] Update Network Presence | -include::../volume2/dev-46/tf2-dev-46-summary.adoc[] +include::transaction-summaries/tf2-dev-46-summary.adoc[] .^| [[vol0_transaction_summary_dev_47,DEV-47 Retrieve Network Presence]] [[transaction_number_dev_47,DEV-47]] DEV-47 | [[transaction_name_retrieve_network_presence,Retrieve Network Presence]] Retrieve Network Presence | -include::../volume2/dev-47/tf2-dev-47-summary.adoc[] +include::transaction-summaries/tf2-dev-47-summary.adoc[] .^| [[vol0_transaction_summary_dev_48, DEV-48 Establish Distributed Alarm System]][[transaction_number_dev_48, DEV-48]] DEV-48 | [[transaction_name_establish_distributed_alarm_system, Establish Distributed Alarm System]] Establish Distributed Alarm System | -include::../volume2/dev-48/tf2-dev-48-summary.adoc[] +include::transaction-summaries/tf2-dev-48-summary.adoc[] .^| [[vol0_transaction_summary_dev_49, DEV-49 End Distributed Alarm System]][[transaction_number_dev_49, DEV-49]] DEV-49 | [[transaction_name_end_distributed_alarm_system, End Distributed Alarm System]] End Distributed Alarm System | -include::../volume2/dev-49/tf2-dev-49-summary.adoc[] +include::transaction-summaries/tf2-dev-49-summary.adoc[] .^| DEV-50 | _Reserved_ | diff --git a/asciidoc/volume0/tf0-ch-d-glossary.adoc b/asciidoc/supplement/volume0/tf0-ch-d-glossary.adoc similarity index 90% rename from asciidoc/volume0/tf0-ch-d-glossary.adoc rename to asciidoc/supplement/volume0/tf0-ch-d-glossary.adoc index d110f307..db60c96c 100644 --- a/asciidoc/volume0/tf0-ch-d-glossary.adoc +++ b/asciidoc/supplement/volume0/tf0-ch-d-glossary.adoc @@ -5,10 +5,12 @@ [%autowidth] [cols="1"] |=== -| *{supplement_note}*: The General Introduction Appendix D Glossary in this initial version of the supplement includes all terms and acronyms that are utilized throughout the other volumes. Subsequent versions of the supplement may re-locate items to other tables and sections within the technical framework. To help differentiate between various classes or categories of terms, a *_new "Type" column_* has been added. This could enable future dynamic resorting of the table by those users who are interested in, for example, only organizational definitions. Finally, a *_References column_* has been added to pull this information out of the Definition column. +| *{supplement_note}*: The General Introduction Appendix D Glossary in this initial version of the standard includes all terms and acronyms that are utilized throughout the other volumes. Subsequent versions of the standard may re-locate items to other tables and sections within the technical framework. To help differentiate between various classes or categories of terms, a *_new "Type" column_* has been added. This could enable future dynamic resorting of the table by those users who are interested in, for example, only organizational definitions. Finally, a *_References column_* has been added to pull this information out of the Definition column. |=== -[%noheader] +// STANDALONE TO DO + +noheader] [%autowidth] [cols="1"] |=== @@ -45,7 +47,8 @@ | A system that supports a multi-patient workplace with capabilities similar to a Cockpit. | | -| See extended description and discussion in <> +| See extended description and discussion in <>, section _System Type Nomenclature Extensions_ +<> | | [[term_classic_dim,Classic DIM]] Classic Domain Information Model (DIM) @@ -70,7 +73,7 @@ | Time | [[term_coded_attribute, Coded Attribute]] Coded Attribute -| A BICEPS Participant Model extension that allows for a <> to provide attributes from the first partition of the IEEE 11073-10101 nomenclature. Specified in <>. +| A BICEPS Participant Model extension that allows for a <> to provide attributes from the first partition of the IEEE 11073-10101 nomenclature. Specified in #LINK OR TEXT - this reference is suspect#:vol3_clause_coded_attribute. | | | See https://www.nist.gov/conformity-assessment[NIST CA resources page] @@ -91,7 +94,7 @@ | SDC | [[term_discovery_scope, Discovery Scope]] Discovery Scope -| A set of zero to many identifiers that allows for organizing <>s into logical groups. +| A set of zero to many identifiers that allows for organizing <> s into logical groups. | | | @@ -198,14 +201,14 @@ | Organization | [[term_medical_data_information_base,Medical Data Information Base (MDIB)]] Medical Data Information Base -| Structured collection of any data objects that are provided by a <> or <>, including both descriptive and state information. +| Structured collection of any data objects that are provided by a <> or <>, including both descriptive and state information. | | [[acronym_mdib,MDIB]] MDIB | <> | SDC | [[term_mdib_configuration, MDIB Configuration]] MDIB Configuration -| <> that describes the state of a <> at a specific MDIB version. +| <> that describes the state of a <> at a specific MDIB version. | | | @@ -327,7 +330,7 @@ elements, from requirements to system components to Verification & Validation te | | [[term_poc_dashboard,PoC Dashboard]] Point of Care Dashboard -| A system that displays information from one or more <> systems associated with a single patient. Similar to a <> but without device-external control capabilities. May include both metric and alert information. +| A system that displays information from one or more <> systems associated with a single patient. Similar to a <> but without device-external control capabilities. May include both metric and alert information. | Dashboard | | @@ -348,7 +351,7 @@ elements, from requirements to system components to Verification & Validation te | | [[term_reference_clock,reference clock]] Reference clock -| The source of time obtained from a <> and shared between <>s. +| The source of time obtained from a <> and shared between <>s. | | | @@ -362,7 +365,7 @@ elements, from requirements to system components to Verification & Validation te | | [[term_removable_subsystem,Removable Subsystem]] Removable Subsystem -| A subsystem of a <> that can be attached to or removed from the <> and that is represented in the <>. +| A subsystem of a <> that can be attached to or removed from the <> and that is represented in the <>. | | | See also <> @@ -440,7 +443,7 @@ implements a service-oriented <> architecture composed of service p | | [[term_somds_provider_uid, SOMDS Provider UID]] SOMDS Provider UID -| A globally unique identifier <> for a <> that is stable across re-initializations (i.e., resets / reboots). +| A globally unique identifier <> for a <> that is stable across re-initializations (i.e., resets / reboots). | [[acronym_uid,UID]] UID | | @@ -454,14 +457,14 @@ implements a service-oriented <> architecture composed of service p | Organization | [[term_system_clock,system clock]] System clock -| A source of <>s used in a <>s system function contributions (<>). +| A source of <>s used in a <>s system function contributions (<>). | | | | Time | [[term_system_function_contribution,System Function Contribution (SFC)]] System Function Contribution -| Function of a <> that contributes to a <> provided by a <>. +| Function of a <> that contributes to a <> provided by a <>. | | [[acronym_sfc,SFC]] SFC | Adapted from <>. @@ -496,7 +499,7 @@ implements a service-oriented <> architecture composed of service p | | [[term_transport_address, Transport Address]] Transport Address -| A physical endpoint address that can be used to communicate with a <> or <> . +| A physical endpoint address that can be used to communicate with a <>. | XAddr | | @@ -511,4 +514,3 @@ implements a service-oriented <> architecture composed of service p |=== - diff --git a/asciidoc/volume0/tf0-main.adoc b/asciidoc/supplement/volume0/tf0-main.adoc similarity index 88% rename from asciidoc/volume0/tf0-main.adoc rename to asciidoc/supplement/volume0/tf0-main.adoc index fe01ea7a..7ef255eb 100644 --- a/asciidoc/volume0/tf0-main.adoc +++ b/asciidoc/supplement/volume0/tf0-main.adoc @@ -6,6 +6,7 @@ The https://profiles.ihe.net/GeneralIntro[IHE Technical Frameworks General Introduction] is shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to this document where appropriate. +// include::tf0-ch-9-copyrights.adoc[] // 10 Trademark @@ -43,11 +44,11 @@ The choice of any namespace prefix is arbitrary and not semantically significant |dp |urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2 -|This specification, used by the <> actor. +|This specification, used by the <> actor. |dpws |http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01 -|<> +| #LINK OR TEXT#:ref_oasis_dpws_2009 |hs |urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.3.1 @@ -59,18 +60,19 @@ The choice of any namespace prefix is arbitrary and not semantically significant |wsa |http://www.w3.org/2005/08/addressing -|<> +| #LINK OR TEXT#:ref_oasis_ws_addressing_2006 |wsd |http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01 -|<> +| #LINK OR TEXT#:ref_oasis_ws_discovery_2009 |wse |http://schemas.xmlsoap.org/ws/2004/08/eventing -|<> +| #LINK OR TEXT#:ref_w3c_ws_eventing_2006 |wsm |http://schemas.xmlsoap.org/ws/2004/09/mex -|<> +| #LINK OR TEXT#:ref_w3c_ws_metadata_exchange_2008 + +|=== -|=== \ No newline at end of file diff --git a/asciidoc/supplement/volume0/transaction-summaries/sdpi-supplement-tf1-ch-2-overview.adoc b/asciidoc/supplement/volume0/transaction-summaries/sdpi-supplement-tf1-ch-2-overview.adoc new file mode 100644 index 00000000..040c1c39 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/sdpi-supplement-tf1-ch-2-overview.adoc @@ -0,0 +1,232 @@ +// Devices Integration Profiles + +// 2. +[#vol1_clause_devices_integration_profiles,sdpi_offset=2] +== Devices Integration Profiles + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: This standard is being written after the 2019 reorganization of the IHE Patient Care Devices (*PCD*) domain to the IHE Devices (*DEV*) domain. +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 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. +|=== + + +// 2.2 +[#vol1_clause_ses_considerations_requirements,sdpi_offset=2] +=== Safety, Effectiveness and Security - Requirements and Considerations +IHE specifications often include sections for "Security Considerations" and "Safety Considerations", capturing both general and specific guidance and requirements for system implementers. +This standard extends these two concepts to include a third: Effectiveness. +The sections are titled "Safety, Effectiveness and Security - Requirements and Considerations" and make use of the underlying term <>. + +//// + +The background for <> is discussed in detail in <>; however, in general "<>" is used as a reference to the standards encompassed (directly and indirectly by reference) in <>, including <> and <>. +These standards are primarily, though not exclusively, focused on *_risk management of health software_* (including <>) *_and medical devices that are deployed on various kinds of infrastructure_*, with a focus to managing three key properties: *Safety, Effectiveness and Security*. +Thus the "Safety, Effectiveness and Security - Requirements and Considerations" sections in this standard are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use. + +Note that specific requirements from the above mentioned standards, may also be captured in <>. +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 + + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 1:10 for SDPi- would have a summary here as 1:2.3.10). No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion in 1:2.3.1 below. + +In this version, the content is added as 1:2.3.1, and then the profiles as 1:2.3.10 to 1:2.3.13. Though the content is valid, it may be repositioned in subsequent versions to better integrate with the IHE DEV TF at a future date. + +*_Omitted from this version are profile-specific option summaries_* (e.g., 3.10.1?). It is unclear where to best place this content, and they are listed explicitly in each profile's detailed specification. + +|=== + +[#vol1_clause_sdpi_integration_profiles_overview] +==== Service-oriented Device Point-of-care Interoperability (SDPi) + + +[#vol1_clause_sdpi_scope] +===== SDPi Profiles – Scope of Application + +The Service-oriented Device Point-of-care Interoperability (SDPi) Profile specifications provide detailed instructions for seamless plug-and-play interoperability between IEEE 11073 SDC-based medical devices (including SaMD), as well as between medical devices and health IT systems based on HL7 FHIR and HL7 Version 2. +Key considerations include enabling safe, secure and effective interoperability for data reporting, alert notification, device-external control and other high-acuity point-of-care use cases. +Provision is made for coordination of individual device functional contributions to support clinical system functions that are provided by two or more participants. + + +Notes: + +1. High-acuity points of care include operating rooms (OR), intensive care units (ICU), step-down units, and emergency care. +2. Clinical system function example: Physiological monitoring of a patient's condition as they are being weaned off of a ventilator. +3. "SaMD" is Software as a Medical Device, including "clinical apps"; they are a class of health software. +4. IEEE 11073 Service-oriented Device Connectivity (SDC) standards provide a Services Oriented Architecture (SOA) specification for safe, effective and secure medical device interoperability (SES MDI). + + +[#vol1_clause_sdpi_overview_framework] +===== SDPi Profiles – Overview & Framework + +//// + +The 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] +image::../images/vol1-diagram-sdpi-profiles.svg[align=center] + +//// + +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? __* + +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. +This is achieved by the use of IHE "grouped actors". +Or IHE "gateway" actors include mappings to the foundational, non-SDC standards. + +The above figure illustrates how this balance was achieved, including: + +//// + +[none] +. *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* +[none] +.. The Profiles are built upon a solid foundation of existing standards from various <>s. Such standards 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 <>. +. *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. +.. The separation of interoperability purposes across four aspects both simplifies the complexity of each functional area, as well as implementation optionality, where some systems may only need to support connectivity and reporting but not alerting nor external control. +.. 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 four Profiles, which together provide a practical, pragmatic way toward genuine <> interoperability: + +[none] +. P -> SDPi-Plug-and-trust +. R -> SDPi-Reporting +. A -> SDPi-Alerting +. 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. +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 <> 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. +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_. +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. +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_*. +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. +Profile options are provided for additional capabilities that may be required to support extended scenarios. + +[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 2026). + +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). + +//// + +// STANDALONE TO DO: #TODO: Add "alert delegation" to the Glossary and reference here# + + +[sdpi_offset=13] +==== Service-oriented Device Point-of-care Interoperability - External Control (SDPi-xC) Profile + +[%noheader] +[%autowidth] +[cols="1"] +|=== +a| *{supplement_note}*: 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 SDPi {ihe_supplement_sdpi_revision_short}_* and even basic controls will not be added until SDPi 3.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_*. +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 #LINK OR TEXT# ref_ieee_11073_10703_202x external control <> standard (in development, anticipated in 2027). + + +[sdpi_offset=5] +=== Dependencies between Integration Profiles + +[%noheader] +[cols="1"] +|=== +| Add the following dependencies below to the IHE DEV TF Profile Dependencies table. +|=== + + +// Standalone TO EDO: #TODO: SHOULD ATNA BE ADDED TO THIS TABLE FOR SOMDS_PARTICIPANT?# + + +[#vol1_table_devices_integration_profile_dependencies] +.Devices Integration Profile Dependencies + +[%autowidth] +[cols="1,1,1,1"] +|=== +.^|Integration Profile +.^|Depends on +.^|Dependency Type +.^|Purpose + +| <> +| Consistent Time (CT) +| Each <> actor implementation (i.e., <>) shall be grouped with the CT Time Client Actor. Note: All <> actors are also grouped with the <> Actor. +| Required for consistent time-stamping of transactions and data. + +| <> +| Device Enterprise Communication (DEC)) +| The <> integrates DEC Device Observation Reporter (DOR) Actor specifications. +| 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 <> and <> to HL7 V2 and ACM transactions. + +|=== + + +//// +#TODO: DO WE NEED TO ALSO MENTION DOC IN AN SDPI 1.X NOTE? WHAT ABOUT DEPENDENCY ON THE IHE DEV TF-2 APPENDIX A V2 GENERAL PROVISIONS?# +//// diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-23-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-23-summary.adoc new file mode 100644 index 00000000..3fd4aedd --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-23-summary.adoc @@ -0,0 +1,4 @@ +// DEV-23 Transaction Summary + +Notify all <>s that a <> is connected to the network and ready to exchange messages with other <>s. + diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-24-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-24-summary.adoc new file mode 100644 index 00000000..b39c29ae --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-24-summary.adoc @@ -0,0 +1,4 @@ +// DEV-24 Transaction Summary + +Discover and resolve all available <>s that a <> is potentially interested in. + diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-25-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-25-summary.adoc new file mode 100644 index 00000000..04dd14ee --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-25-summary.adoc @@ -0,0 +1,4 @@ +// DEV-25 Transaction Summary + +Exchange resources metadata between a <> and a <>. + diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-27-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-27-summary.adoc new file mode 100644 index 00000000..1e8f7791 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-27-summary.adoc @@ -0,0 +1,4 @@ +// DEV-27 Transaction Summary + +Establish a publish-subscribe session between a <>, acting as the event source, and a <>, acting as the event sink. + diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-28-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-28-summary.adoc new file mode 100644 index 00000000..b16863f9 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-28-summary.adoc @@ -0,0 +1,3 @@ +// DEV-28 Transaction Summary + +Notify a <> about changes in system context and capabilities of a <>. \ No newline at end of file diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-29-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-29-summary.adoc new file mode 100644 index 00000000..b9dc2c25 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-29-summary.adoc @@ -0,0 +1,3 @@ +// DEV-29 Transaction Summary + +Notify a <> about changes in the alert, metric, component, description modification and operational state reports and in the waveform stream of a <>. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-30-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-30-summary.adoc new file mode 100644 index 00000000..95b17f2f --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-30-summary.adoc @@ -0,0 +1,3 @@ +// DEV-32 Transaction Summary + +Retrieve historic <> data of a <> a <> is interested in. \ No newline at end of file diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-32-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-32-summary.adoc new file mode 100644 index 00000000..2a0887a5 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-32-summary.adoc @@ -0,0 +1,3 @@ +// DEV-32 Transaction Summary + +Establishes a subscription (see <>) and produces a stream of messages that reflect historic <> data. \ No newline at end of file diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-33-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-33-summary.adoc new file mode 100644 index 00000000..3a13b962 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-33-summary.adoc @@ -0,0 +1,3 @@ +// DEV-33 Transaction Summary + +Retrieve localized texts of a <> a <> is interested in. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-35-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-35-summary.adoc new file mode 100644 index 00000000..80ad48d3 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-35-summary.adoc @@ -0,0 +1,3 @@ +// DEV-35 Transaction Summary + +Establish the exchange of medical data between a <> and a <>. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-36-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-36-summary.adoc new file mode 100644 index 00000000..498a0be2 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-36-summary.adoc @@ -0,0 +1,3 @@ +// DEV-36 Transaction Summary + +Publish medical data from a <> to a <>. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-37-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-37-summary.adoc new file mode 100644 index 00000000..cafe5433 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-37-summary.adoc @@ -0,0 +1,4 @@ +// DEV-37 Transaction Summary + +Retrieve medical data from a <>. + diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-38-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-38-summary.adoc new file mode 100644 index 00000000..a9bc690e --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-38-summary.adoc @@ -0,0 +1,3 @@ +// DEV-38 Transaction Summary + +Establish the exchange of medical alerts from a <> to a <>. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-39-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-39-summary.adoc new file mode 100644 index 00000000..5158759e --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-39-summary.adoc @@ -0,0 +1,3 @@ +// DEV-39 Transaction Summary + +Notify a <> about changes in the medical alert status of a <>. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-40-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-40-summary.adoc new file mode 100644 index 00000000..9cdb5568 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-40-summary.adoc @@ -0,0 +1,3 @@ +// DEV-40 Transaction Summary + +Retrieve the medical alert status of a <>. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-46-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-46-summary.adoc new file mode 100644 index 00000000..36ba4b38 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-46-summary.adoc @@ -0,0 +1,3 @@ +// DEV-46 Transaction Summary + +Provide network presence and absence of <> Actors in a <> network by updating the metadata in a <> Actor. diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-47-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-47-summary.adoc new file mode 100644 index 00000000..ebb8d4f2 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-47-summary.adoc @@ -0,0 +1,3 @@ +// DEV-47 Transaction Summary + +Retrieve presence metadata from a <> Actor for a specified set of <> Actors that may be connected to a <> network. \ No newline at end of file diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-48-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-48-summary.adoc new file mode 100644 index 00000000..238f4c6b --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-48-summary.adoc @@ -0,0 +1,3 @@ +// DEV-48 Transaction Summary + +Establish a Distributed Alarm System between a <> and a <>. \ No newline at end of file diff --git a/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-49-summary.adoc b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-49-summary.adoc new file mode 100644 index 00000000..dff69f38 --- /dev/null +++ b/asciidoc/supplement/volume0/transaction-summaries/tf2-dev-49-summary.adoc @@ -0,0 +1,3 @@ +// DEV-49 Transaction Summary + +Intentionally end the Distributed Alarm System between a <> and a <>. \ No newline at end of file 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 e5815bd5..7b4acd9e 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 @@ -6,7 +6,7 @@ [%autowidth] [cols="1"] |=== -| *{supplement_note}*: This section is provided as a placeholder for the <> table specification that will be added in a subsequent SDPi supplement version. +| *{standard_note}*: This section is provided as a placeholder for the <> table specification that will be added in a subsequent SDPi standard version. The tables will have an additional SDPi column added to the right side that indicates *if* and TBD *where* the requirement is satisfied. Requirement Definition (this table's rows) will be referenced where they are satisfied; however, these tables may also include forward references, at least in general, to what capabilities / requirements satisfy the referenced standard requirement. @@ -42,7 +42,7 @@ ADD IEEE: *Remote Control ICS table here* [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Context processing pertains to effective utilization of context information like workflow (e.g., orders) info, patient demographics and locations. +a| *{standard_note}*: Context processing pertains to effective utilization of context information like workflow (e.g., orders) info, patient demographics and locations. A future version of SDPi will describe how to cope with contexts, with device coupling mechanisms described informally in TF-1 and formally in TF-2 (possibly as a transaction). |=== diff --git a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc index cdbb80fa..f54ccd2e 100644 --- a/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc +++ b/asciidoc/volume1/tf1-ch-10-sdpi-p.adoc @@ -26,7 +26,7 @@ For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Ca [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Some actors and transactions have been deferred to a subsequent version, but are included here for completeness. +a| *{standard_note}*: Some actors and transactions have been deferred to a subsequent version, but are included here for completeness. Specifically: SOMDS Sensor Gateway and SOMDS Smart App Platform have been deferred. Deferred transactions have been so indicated in the transactions table. @@ -222,7 +222,7 @@ 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). @@ -278,7 +278,7 @@ Generally, the <> supports messaging fr [%autowidth] [cols="1"] |=== -| *{supplement_note}*: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement. +| *{standard_note}*: Detailed specifications for this actor are deferred to a later version of the SDPi standard. |=== [#vol1_spec_sdpi_p_actor_somds_sensor_gateway, reftext='SOMDS Sensor Gateway',role=actor-alias,actor-id="somds_sensor_gateway"] @@ -298,7 +298,7 @@ This also includes SOMDS integration of IoT (“Internet of Things”) architect [%autowidth] [cols="1"] |=== -| *{supplement_note}*: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement. +| *{standard_note}*: Detailed specifications for this actor are deferred to a later version of the SDPi standard. |=== [#vol1_spec_sdpi_p_actor_somds_smart_app_platform, reftext='SOMDS Smart App Platform',role=actor-alias,actor-id="somds_smart_app"] @@ -352,7 +352,7 @@ Actor Summary Definition: [none] . Processes <> information conformant to <> BICEPS specifications provided by <> systems. -A <> shall be capable of processing information provided by a <>, in accordance to the BICEPS content module specifications in <> and related sections. +A <> shall be capable of processing information provided by a <>, in accordance to the BICEPS content module specifications in <> and related sections. //// @@ -362,7 +362,7 @@ The supported BICEPS content processing shall include one or more of the options //// -For robustness, a <> need only process the content that is necessary to support its capabilities, but shall also be able to accept any additional content that may be provided but is out-of-scope for its internal requirements. footnote:[Apply Postel’s Law: Send conservatively, Accept liberally.] +For robustness, a <> need only process the content that is necessary to support its capabilities, but shall also be able to accept any additional content that may be provided but is out-of-scope for its internal requirements. footnote:[Apply Postel’s Law: Send conservatively, Accept liberally.] Note that although this SDPi-P content actor primarily supports information exchange between systems participating in a SOMDS network environment, they may be referenced by other non-SDPi profiles that utilize other non-SOMDS exchange architectures, transactions and technologies. @@ -917,7 +917,7 @@ Specific <> transaction message bindings and [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -931,7 +931,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -947,7 +947,7 @@ Integration of CT and ATNA (TBD) below in required groupings is assumed but shou [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -961,7 +961,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -979,7 +979,7 @@ See Gateways in the actors discussion above … and below? [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -994,7 +994,7 @@ Given the discussion in Actors above, is this necessary here? Or should some of [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -1007,7 +1007,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// //// @@ -1020,7 +1020,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// diff --git a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc index 4a3e782f..5fc525f2 100644 --- a/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc +++ b/asciidoc/volume1/tf1-ch-11-sdpi-r.adoc @@ -7,12 +7,12 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This version of the <> Profile is built upon the foundational <> Profile but does not provide substantially more capabilities. +a| *{standard_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 full integration of two emerging 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. +Their requirements will be integrated into this standard, with their <> added to <> below. +Many of those requirements will be mapped to the actors and transactions and other elements in this standard, 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. +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 standard. |=== @@ -190,9 +190,9 @@ Actor Summary Definition: [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The HL7 FHIR resources and related Point-of-Care Device FHIR Implementation Guide (PoCD FHIR IG) is still under active development. +a| *{standard_note}*: The HL7 FHIR resources and related Point-of-Care Device FHIR Implementation Guide (PoCD FHIR IG) is still under active development. Initial mappings have been made from <> to <>; however, they are not yet ready for profiling and product implementation. -When the FHIR specifications are finalized, then this actor will be fully specified in a future SDPI Supplement version. +When the FHIR specifications are finalized, then this actor will be fully specified in a future SDPI standard version. See <> for additional information. |=== @@ -215,14 +215,14 @@ No options are defined for this profile. // [%autowidth] // [cols="1"] // |=== -// a| *{supplement_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. +// a| *{standard_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi standard. // // [#vol1_clause_sdpi_r_actor_option_retrieve_remote_data_reftext, reftext='SDPi-R Option: Retrieve Remote Data'] // [%noheader] // [%autowidth] // [cols="1"] // |=== -// a| *{supplement_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. +// a| *{standard_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi standard. // // This option will enable <> systems to access information in remote systems that are not part of its <> network instance. This access will be provided by either a <> or <>. // For example, retrieving the latest laboratory information for a specific patient. @@ -280,7 +280,7 @@ If this is a content profile, and actors from this profile are grouped with acto [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: An overview of the concepts for this <> will be provided in a future supplement version. +a| *{standard_note}*: An overview of the concepts for this <> will be provided in a future SDPi standard version. Note that this specification extends the concepts established in the base <>. |=== @@ -345,8 +345,8 @@ A primary source of safety requirements for this <> Profile come [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The <> and <> standards are now published by the IEEE. -However, their requirements are yet to be integrated into this supplement, with many of them being mapped to elements in this <> Profile. +a| *{standard_note}*: The <> and <> standards are now published by the IEEE. +However, their requirements are yet to be integrated into this standard, with many of them being mapped to elements in this <> Profile. |=== diff --git a/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc b/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc index 3833ff25..1e6467f6 100644 --- a/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc +++ b/asciidoc/volume1/tf1-ch-12-sdpi-a.adoc @@ -7,17 +7,17 @@ [%autowidth] [cols="1"] |=== -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. +a| *{standard_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 IEEE 11073 Alert <> standard <>. -When this new standard is published, 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 standard, 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 <> and the External Control <> standard <>. -As a result, the completion of these two transactions has been deferred to a subsequent version of the supplement. +As a result, the completion of these two transactions has been deferred to a subsequent version of the standard. -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 standard. -Finally, it should be noted that <> is defined below and fully specified in <>. +Finally, it should be noted that <> is defined below and fully specified in <>. Also in development is <> <> support for medical alerting (e.g., refinement of the <> DeviceAlert resource and future development of a <> Device Alerting IG). 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. @@ -122,7 +122,7 @@ include::../plantuml/vol1-figure-sdpi-a-reporting-example-sequence-diagram.puml[ [#vol1_spec_sdpi_a_actor_somds_medical_alert_provider, reftext='SOMDS Medical Alert Provider',role="actor-alias",actor-id="somds_medical_alert_provider"] Actor Summary Definition: [none] -. A <> grouped actor that sends medical alert information to a <>. +. A <> grouped actor that sends medical alert information to a <>. This actor is designed to publish medical device alert information to a <>, which in turn can communicate it safely and reliably to a clinician. Transactions enabled for this actor are identified in <> above. @@ -215,7 +215,7 @@ sdpi_include_transaction::DEV-42[actor-id="somds_medical_alert_consumer",respond [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This section is intentionally left incomplete to indicate capabilities that will be added in a future version of the SDPi Supplement. +a| *{standard_note}*: This section is intentionally left incomplete to indicate capabilities that will be added in a future version of the SDPi standard. As stated elsewhere, the completion of the <> and <> standards is required before this profile can be fully completed (beyond alert reporting for DIS capabilities and DAS capabilities without delegation), and that is especially the case for alert delegation. *_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._* @@ -251,7 +251,7 @@ include::../plantuml/vol1-figure-sdpi-a-delegation-example-sequence-diagram.puml [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. +a| *{standard_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi standard. 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. @@ -270,7 +270,7 @@ sdpi_include_transaction::DEV-40[actor-id="somds_acm_gateway",initiator="optiona [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. +a| *{standard_note}*: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi standard. This option will enable <> systems to receive [DEV-04]/[PCD-04] transactions from an ACM Alert Reporter 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. @@ -326,7 +326,7 @@ If this is a content profile, and actors from this profile are grouped with acto [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: An overview of the concepts for this <> will be provided in a future supplement version. +a| *{standard_note}*: An overview of the concepts for this <> will be provided in a future SDPi standard version. Note that this specification extends the concepts established in the base <>. |=== diff --git a/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc b/asciidoc/volume1/tf1-ch-13-sdpi-xc.adoc index 7536bdba..90a92e47 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 as part of the 3.X or 4.X versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading). +a| *{standard_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 3.X or 4.X versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading). |=== @@ -158,7 +158,7 @@ If this is a content profile, and actors from this profile are grouped with acto [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: An overview of the concepts for this <> will be provided in a future supplement version. +a| *{standard_note}*: An overview of the concepts for this <> will be provided in a future standard version. Note that this specification extends the concepts established in the base <>. |=== @@ -169,7 +169,7 @@ Note that this specification extends the concepts established in the base <>. The background for <> is discussed in detail in <>; however, in general "<>" is used as a reference to the standards encompassed (directly and indirectly by reference) in <>, including <> and <>. These standards are primarily, though not exclusively, focused on *_risk management of health software_* (including <>) *_and medical devices that are deployed on various kinds of infrastructure_*, with a focus to managing three key properties: *Safety, Effectiveness and Security*. -Thus the "Safety, Effectiveness and Security - Requirements and Considerations" sections in this supplement are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use. +Thus the "Safety, Effectiveness and Security - Requirements and Considerations" sections in this standard are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use. Note that specific requirements from the above mentioned standards, may also be captured in <>. Generally, requirements from these standards would be mapped to the appropriate "Safety, Effectiveness and Security - Requirements and Considerations" sections throughout the specification. @@ -44,7 +44,7 @@ Implementers must ensure that all appropriate risk management processes have bee [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 1:10 for SDPi- would have a summary here as 1:2.3.10). No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion in 1:2.3.1 below. +a| *{standard_note}*: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 1:10 for SDPi- would have a summary here as 1:2.3.10). No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion in 1:2.3.1 below. In this version, the content is added as 1:2.3.1, and then the profiles as 1:2.3.10 to 1:2.3.13. Though the content is valid, it may be repositioned in subsequent versions to better integrate with the IHE DEV TF at a future date. @@ -164,8 +164,8 @@ Profile options are provided for additional capabilities that may be required to [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: 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 SDPi {ihe_supplement_sdpi_revision_short}_* and even basic controls will not be added until SDPi 3.0 or later. +a| *{standard_note}*: 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 SDPi {gemini_standard_sdpi_revision_short}_* and even basic controls will not be added until SDPi 3.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_*. @@ -204,12 +204,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. +| The <> integrates DEC Device Observation Reporter (DOR) Actor specifications. | Required for mapping from <> and <> to HL7 V2 and DEC transactions. | <> | Alert Communication Management (ACM) -| The <> integrates ACM Alert Reporter (AR) Actor specifications. +| The <> integrates ACM Alert Reporter (AR) Actor specifications. | 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 7fc86877..a06eb485 100644 --- a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc +++ b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc @@ -140,7 +140,7 @@ No additional security requirements and considerations are identified for this t [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The information in this section includes both general requirements modeling information that captures the metadata that is ultimately exported for document-external use. +a| *{standard_note}*: The information in this section includes both general requirements modeling information that captures the metadata that is ultimately exported for document-external use. It also includes specific AsciiDoc information (e.g., element labels) to facilitate review by providing all the related information in one location. Ultimately, the AsciiDoc and related information that is used for specification production and requirement exportation (e.g., export JSON mapping and file format), will be moved to a separate article or paper. @@ -457,7 +457,7 @@ image::../images/vol1-diagram-sdpi-req-use-case-feature.svg[align=center] [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Additional detail will be added in a subsequent version. Additional metadata may include: +a| *{standard_note}*: Additional detail will be added in a subsequent version. Additional metadata may include: . Use Case Identifier . Use case element type and identifier @@ -473,7 +473,7 @@ a| *{supplement_note}*: Additional detail will be added in a subsequent version. [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Additional detail will be added in a subsequent version. Additional metadata may include: +a| *{standard_note}*: Additional detail will be added in a subsequent version. Additional metadata may include: . Referenced Standard (document identifier, version and date; may be a link to the referenced standard section of the specification) . Source requirement identifier in referenced standard @@ -496,7 +496,7 @@ NOTE: Requirements from SES referenced standards such as <> for normative definitions for these terms. -NOTE: Note that the {ihe_supplement_sdpi_revision_short} version of the SDPi Profile only supports the Distributed Information System (DIS) model detailed below. +NOTE: Note that the {gemini_standard_sdpi_revision_short} version of the SDPi Profile only supports the Distributed Information System (DIS) model detailed below. The other models are anticipated for subsequent versions. 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 1028c903..9bcd45ca 100644 --- a/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc +++ b/asciidoc/volume1/use-cases/tf1-ch-c-use-cases.adoc @@ -11,8 +11,8 @@ [%autowidth] [cols="1"] |=== -| *{supplement_note}*: This initial section of Appendix C is informative and is still being detailed. Completion is deferred to a later version of SDPi. -It provides general background detail around how general (non-technology specific) clinical use case specifications are being utilized in this supplement. +| *{standard_note}*: This initial section of Appendix C is informative and is still being detailed. Completion is deferred to a later version of SDPi. +It provides general background detail around how general (non-technology specific) clinical use case specifications are being utilized in this standard. *REVIEWER QUESTION*: Please review the intended topics and identify any additional content that should be considered. Especially helpful would be references to related standards and materials that would inform the approach taken in this appendix. |=== @@ -33,7 +33,7 @@ Looking to leverage this wealth of use cases in considering SDPi, a "compendium [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// @@ -46,7 +46,7 @@ a| *{supplement_note}*: This section intentionally left blank for the current v [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This section contains initial content that will be greatly expanded in future versions. +a| *{standard_note}*: This section contains initial content that will be greatly expanded in future versions. |=== //// @@ -70,7 +70,7 @@ Each Use Case (also called a Feature in Gherkin) is organized as follows: [%autowidth] [cols="1"] |=== -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. +a| *{standard_note}*: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |=== //// diff --git a/asciidoc/volume2/dev-34/tf2-ch-a-mdpws-dev-34.adoc b/asciidoc/volume2/dev-34/tf2-ch-a-mdpws-dev-34.adoc index 5ed14201..7b962452 100644 --- a/asciidoc/volume2/dev-34/tf2-ch-a-mdpws-dev-34.adoc +++ b/asciidoc/volume2/dev-34/tf2-ch-a-mdpws-dev-34.adoc @@ -10,7 +10,7 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The former transaction Announce Network Departure [{var_transaction_id}] was withdrawn with SDPi 2.2. Therefore, it is marked as _Reserved_. +a| *{standard_note}*: The former transaction Announce Network Departure [{var_transaction_id}] was withdrawn with SDPi 2.2. Therefore, it is marked as _Reserved_. |=== //// diff --git a/asciidoc/volume2/dev-34/tf2-dev-34.adoc b/asciidoc/volume2/dev-34/tf2-dev-34.adoc index f2f53a9d..1d04081a 100644 --- a/asciidoc/volume2/dev-34/tf2-dev-34.adoc +++ b/asciidoc/volume2/dev-34/tf2-dev-34.adoc @@ -13,7 +13,7 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The former transaction Announce Network Departure [{var_transaction_id}] was withdrawn with SDPi 2.2. Therefore, it is marked as _Reserved_. +a| *{standard_note}*: The former transaction Announce Network Departure [{var_transaction_id}] was withdrawn with SDPi 2.2. Therefore, it is marked as _Reserved_. |=== //// ==== Scope diff --git a/asciidoc/volume2/dev-46/tf2-dev-46-summary.adoc b/asciidoc/volume2/dev-46/tf2-dev-46-summary.adoc index 36ba4b38..53969665 100644 --- a/asciidoc/volume2/dev-46/tf2-dev-46-summary.adoc +++ b/asciidoc/volume2/dev-46/tf2-dev-46-summary.adoc @@ -1,3 +1,4 @@ // DEV-46 Transaction Summary -Provide network presence and absence of <> Actors in a <> network by updating the metadata in a <> Actor. +Provide network presence and absence of <> Actors in a <> network by updating the metadata in a <> Actor. + diff --git a/asciidoc/volume2/dev-47/tf2-dev-47-summary.adoc b/asciidoc/volume2/dev-47/tf2-dev-47-summary.adoc index ebb8d4f2..e2c271ef 100644 --- a/asciidoc/volume2/dev-47/tf2-dev-47-summary.adoc +++ b/asciidoc/volume2/dev-47/tf2-dev-47-summary.adoc @@ -1,3 +1,4 @@ // DEV-47 Transaction Summary -Retrieve presence metadata from a <> Actor for a specified set of <> Actors that may be connected to a <> network. \ No newline at end of file +Retrieve presence metadata from a <> Actor for a specified set of <> Actors that may be connected to a <> network. + diff --git a/asciidoc/volume2/dev-48/tf2-dev-48.adoc b/asciidoc/volume2/dev-48/tf2-dev-48.adoc index 8f0f5b82..bd66510e 100644 --- a/asciidoc/volume2/dev-48/tf2-dev-48.adoc +++ b/asciidoc/volume2/dev-48/tf2-dev-48.adoc @@ -15,7 +15,7 @@ [%autowidth] [cols="1"] |=== -a| *SDPi {ihe_supplement_sdpi_revision_short} Supplement -- _STU / TI Version_ -- Note*: +a| *SDPi {gemini_standard_sdpi_revision_short} Standard -- _STU / TI Version_ -- Note*: This transaction is INFORMATIVE, given that it is based on the mature draft, but not yet finalized, IEEE 11073-10702 (Alert PKP) standard. However, it is included to provide a pathway to early experience and validation. Once the IEEE 11073-10702 standard is finalized and published, this transaction will be updated to be normative. diff --git a/asciidoc/volume2/dev-49/tf2-dev-49.adoc b/asciidoc/volume2/dev-49/tf2-dev-49.adoc index aa88d25e..d0cf09df 100644 --- a/asciidoc/volume2/dev-49/tf2-dev-49.adoc +++ b/asciidoc/volume2/dev-49/tf2-dev-49.adoc @@ -13,7 +13,7 @@ [%autowidth] [cols="1"] |=== -a| *SDPi {ihe_supplement_sdpi_revision_short} Supplement -- _STU / TI Version_ -- Note*: +a| *SDPi {gemini_standard_sdpi_revision_short} Standard -- _STU / TI Version_ -- Note*: This transaction is INFORMATIVE, given that it is based on the mature draft, but not yet finalized, IEEE 11073-10702 (Alert PKP) standard. However, it is included to provide a pathway to early experience and validation. Once the IEEE 11073-10702 standard is finalized and published, this transaction will be updated to be normative. diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc index bc6b45fe..69f1d75f 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-acm.adoc @@ -4,7 +4,7 @@ ==== 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 <>. -The <> represents the Alarm Reporter (AR) role of the IHE ACM profile. +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. @@ -41,7 +41,7 @@ The HL7 Observation Request (OBR) segment requires a mapping from the SDC contai **** [NORMATIVE] ==== -For the IHE ACM profile, the <> shall set the OBR-2 field to the identifier of the Alarm Reporter (AR) of the IHE ACM gateway (not the individual device identifier). +For the IHE ACM profile, the <> shall set the OBR-2 field to the identifier of the Alarm Reporter (AR) of the IHE ACM gateway (not the individual device identifier). ==== [NOTE] @@ -57,7 +57,7 @@ For further information, please refer to the <>. **** [NORMATIVE] ==== -A <> shall set the OBR-3 field to a unique identifier for the status to the alert indication. +A <> shall set the OBR-3 field to a unique identifier for the status to the alert indication. ==== [NOTE] @@ -73,7 +73,7 @@ The content depends on the state of the alert event: **** [NORMATIVE] ==== -For the *initial alert event announcement message*, a <> shall set the OBR-3/EI-1 field to the unique identifier for the alert event. +For the *initial alert event announcement message*, a <> shall set the OBR-3/EI-1 field to the unique identifier for the alert event. ==== [NOTE] @@ -100,7 +100,7 @@ Unique Alert Event Identifier: **** [NORMATIVE] ==== -For the *subsequent alert event messages for the same alert event*, a <> shall set the OBR-3/EI-1 field to the unique identifier of the alert event message that relates to the same alert event as announced in the initial alert event message. +For the *subsequent alert event messages for the same alert event*, a <> shall set the OBR-3/EI-1 field to the unique identifier of the alert event message that relates to the same alert event as announced in the initial alert event message. ==== [NOTE] @@ -152,7 +152,7 @@ The table <> defines the mapping of the Alert Event Id **** [NORMATIVE] ==== -A <> shall set the OBR-4 field to *"196616\^MDC_EVT_ALARM^MDC"*. +A <> shall set the OBR-4 field to *"196616\^MDC_EVT_ALARM^MDC"*. ==== **** @@ -162,7 +162,7 @@ A <> shall set the OBR-4 field to *"196616\^MDC_EVT_ALA **** [NORMATIVE] ==== -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. +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. ==== [NOTE] @@ -178,7 +178,7 @@ Please refer to the *Appendix B B.7.1 OBR Observation Request Segment in ACM Tr **** [NORMATIVE] ==== -A <> shall set the OBR-29 field to the unique alert event identifier of the initial alert event message as defined for the OBR-3 field. +A <> shall set the OBR-29 field to the unique alert event identifier of the initial alert event message as defined for the OBR-3 field. ==== [NOTE] @@ -254,7 +254,7 @@ Please refer to general Section <>. **** [NORMATIVE] ==== -A <> shall export device-related OBX segments, which define the hierarchical relationship of the alert event in the device's containment tree. +A <> shall export device-related OBX segments, which define the hierarchical relationship of the alert event in the device's containment tree. ==== [NOTE] @@ -345,7 +345,7 @@ OBX|3||69855\^MDC_DEV_METER_PRESS_BLD_CHAN^MDC|1.1.1.0|||||||X [NORMATIVE] ==== -A <> shall export an Event Identification OBX segment which identifies the alert event. +A <> shall export an Event Identification OBX segment which identifies the alert event. ==== [NOTE] @@ -360,7 +360,7 @@ The mapping differs for physiological alert events and technical/advisory alert [NORMATIVE] ==== -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. ==== **** @@ -372,7 +372,7 @@ A <> shall report the Alert Event Phase as "update" whe **** [NORMATIVE] ==== -A <> shall set the OBX-14 field of the Event Identification OBX segment to the date/time of the alert event status change. +A <> shall set the OBX-14 field of the Event Identification OBX segment to the date/time of the alert event status change. ==== [NOTE] @@ -630,7 +630,7 @@ OBX|4|CWE|196616\^MDC_EVT_ALARM^MDC|1.1.1.1.1|196882\^MDC_EVT_LEADS_OFF^MDC^^^^^ **** [NORMATIVE] ==== -A <> shall export a Source Identification OBX segment, which identifies the source that led to the alert event. +A <> shall export a Source Identification OBX segment, which identifies the source that led to the alert event. ==== [NOTE] @@ -648,7 +648,7 @@ A <> shall export a Source Identification OBX segment, **** [NORMATIVE] ==== -For a physiological alert event, a <> shall set the OBX-3 field in the <> to the source identifier. +For a physiological alert event, a <> shall set the OBX-3 field in the <> to the source identifier. ==== **** @@ -657,7 +657,7 @@ For a physiological alert event, a <> shall set the OBX **** [NORMATIVE] ==== -For a technical or advisory alert event, a <> shall set the OBX-5 field in the <> to the source identifier. +For a technical or advisory alert event, a <> shall set the OBX-5 field in the <> to the source identifier. ==== **** @@ -668,7 +668,7 @@ For a technical or advisory alert event, a <> shall set **** [NORMATIVE] ==== -A <> shall map the source identification for physiological alerts (alarms or advisories) to an OBX segment as defined in <>. The gateway captures the state of the related metric at the time the alert event occurred. +A <> shall map the source identification for physiological alerts (alarms or advisories) to an OBX segment as defined in <>. The gateway captures the state of the related metric at the time the alert event occurred. ==== [NOTE] @@ -682,7 +682,7 @@ In SDC, the metric value that led to the physiological alert event is required t **** [NORMATIVE] ==== -A <> shall set the OBX-4 Observation Sub-ID to *"....2"* where **, **, **, and ** are the numbers of the device’s containment tree levels assigned by the gateway. +A <> shall set the OBX-4 Observation Sub-ID to *"....2"* where **, **, **, and ** are the numbers of the device’s containment tree levels assigned by the gateway. ==== **** @@ -691,7 +691,7 @@ A <> shall set the OBX-4 Observation Sub-ID to *". **** [NORMATIVE] ==== -A <> shall set the OBX-11 Observation Result Status to *"R"*. +A <> shall set the OBX-11 Observation Result Status to *"R"*. ==== **** @@ -800,7 +800,7 @@ OBX|5|CWE|68480\^MDC_ATTR_ALERT_SOURCE^MDC|1.1.1.1.2|131328\^MDC_ECG_ELEC_POTL^M **** [NORMATIVE] ==== -A <> shall export an Event Phase OBX segment, which identifies the alert event phase. +A <> shall export an Event Phase OBX segment, which identifies the alert event phase. ==== [NOTE] @@ -824,7 +824,7 @@ OBX|6|ST|68481\^MDC_ATTR_EVENT_PHASE^MDC|1.1.1.1.3|start||||||R [NORMATIVE] ==== -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. ==== **** @@ -920,7 +920,7 @@ all the *pm:AlertSignalState* elements with *@ActivationState* set to *"On"* tra **** [NORMATIVE] ==== -A <> shall export an Alert State OBX segment, which defines the current state of the alert event. +A <> shall export an Alert State OBX segment, which defines the current state of the alert event. ==== [NOTE] @@ -943,7 +943,7 @@ OBX|7|ST|68482\^MDC_ATTR_ALARM_STATE^MDC|1.1.1.1.4|active||||||R **** [NORMATIVE] ==== -A <> shall only report an inactive alert condition when the alarm condition transitioned from active or latched to inactive. +A <> shall only report an inactive alert condition when the alarm condition transitioned from active or latched to inactive. ==== **** @@ -1019,7 +1019,7 @@ at least one of the *pm:AlertSignalState* elements with *@ActivationState* set t **** [NORMATIVE] ==== -A <> shall export an Inactivation State OBX segment, which defines the current inactivation state of the alert event. +A <> shall export an Inactivation State OBX segment, which defines the current inactivation state of the alert event. ==== [NOTE] @@ -1122,7 +1122,7 @@ all *pm:AlertSignalState* elements have their *@ActivationState* set to *"Off"* **** [NORMATIVE] ==== -A <> shall map the SDC *pm:AlertConditionDescriptor/@Priority* attribute to an IHE ACM Alert Priority OBX segment as defined in the <>. +A <> shall map the SDC *pm:AlertConditionDescriptor/@Priority* attribute to an IHE ACM Alert Priority OBX segment as defined in the <>. ==== [NOTE] @@ -1240,7 +1240,7 @@ If a <> ALERT CONDITION represents an advisory signal, the alert pr **** [NORMATIVE] ==== -A <> shall map the SDC *pm:AlertConditionDescriptor/@Kind* to an IHE ACM Alert Type OBX segment as defined in the <>. +A <> shall map the SDC *pm:AlertConditionDescriptor/@Kind* to an IHE ACM Alert Type OBX segment as defined in the <>. ==== [NOTE] diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc index 84b53d1d..a2afec8a 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-dec.adoc @@ -4,7 +4,7 @@ ==== 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 <>. -The <> represents the Device Observation Reporter (DOR) role of the IHE DEC profile. +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. @@ -37,7 +37,7 @@ The *pm:PatientContextState/pm:CoreData* element may also contain elements for a **** [NORMATIVE] ==== -If available, the <> shall export height and weight as OBX segments on the MDS level. +If available, the <> shall export height and weight as OBX segments on the MDS level. ==== [NOTE] @@ -62,7 +62,7 @@ The problem is that when the gateway loses connection to the PoC device it can o **** [NORMATIVE] ==== -A <> shall use the *pm:PatientContextState/@BindingStartTime* as the timestamp for the height and weight observation and send new values as corrected results. +A <> shall use the *pm:PatientContextState/@BindingStartTime* as the timestamp for the height and weight observation and send new values as corrected results. ==== **** @@ -255,7 +255,7 @@ The HL7 Observation Request (OBR) segment requires a mapping from the SDC contai [NORMATIVE] ==== -For the IHE DEC profile, the <> shall set the OBR-2 field to the identifier of the Device Observation Reporter (DOR) of the IHE DEC gateway (not the individual device identifier). +For the IHE DEC profile, the <> shall set the OBR-2 field to the identifier of the Device Observation Reporter (DOR) of the IHE DEC gateway (not the individual device identifier). ==== [NOTE] @@ -272,7 +272,7 @@ For further information, please refer to the <>. [NORMATIVE] ==== -For the IHE DEC profile, the <> shall set the OBR-3 field to the identifier of the Device Observation Reporter (DOR) of the IHE DEC gateway (not the individual device identifier). +For the IHE DEC profile, the <> shall set the OBR-3 field to the identifier of the Device Observation Reporter (DOR) of the IHE DEC gateway (not the individual device identifier). ==== [NOTE] @@ -289,7 +289,7 @@ For further information, please refer to the <>. [NORMATIVE] ==== -For the IHE DEC profile, the <> shall set the OBR-4 field to the service identifier of the <>. +For the IHE DEC profile, the <> shall set the OBR-4 field to the service identifier of the <>. ==== [NOTE] @@ -302,7 +302,7 @@ For further information, please refer to the <>. [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: In this version of the SDPi Supplement, this section needs to be updated in order to be compliant with the <>. +a| *{standard_note}*: In this version of the SDPi Standard, this section needs to be updated in order to be compliant with the <>. The following issues need more investigations and discussions: // Note that with IHE PCD TF2 2024 MDC codes are allowed in OBR-4 field. @@ -326,12 +326,12 @@ The absence of an overriding time point in the OBX-14 field implies that this is [NORMATIVE] ==== -A <> shall export continuously (periodically) measured metrics periodically at a defined interval. +A <> shall export continuously (periodically) measured metrics periodically at a defined interval. ==== [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. +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. ==== **** @@ -341,12 +341,12 @@ It is up to the <> how the export interval is defined. [NORMATIVE] ==== -A <> shall set the OBR-7 field to the start date and time of current export interval. +A <> shall set the OBR-7 field to the start date and time of current export interval. ==== [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. +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. ==== **** @@ -356,7 +356,7 @@ If, for example, the export interval is set to 30 seconds, the <> shall export the latest metric value of all continuously (periodically) measured metrics with a *pm:AbstractMetricState++++++/pm:MetricValue++++++/@DeterminationTime* which is equal or greater than the start date and time of the current interval, and less than the start date and time of the next export interval. +A <> shall export the latest metric value of all continuously (periodically) measured metrics with a *pm:AbstractMetricState++++++/pm:MetricValue++++++/@DeterminationTime* which is equal or greater than the start date and time of the current interval, and less than the start date and time of the next export interval. ==== [NOTE] @@ -371,7 +371,7 @@ The OBR-7 field is set to the start time of the interval. The individual periodi [NORMATIVE] ==== -For exporting episodic metric values and the absence of any continuously measured metric values for the current export interval, a <> shall set the OBR-7 field to the start date and time of current export interval. +For exporting episodic metric values and the absence of any continuously measured metric values for the current export interval, a <> shall set the OBR-7 field to the start date and time of current export interval. ==== [NOTE] @@ -383,7 +383,7 @@ For exporting episodic metric values and the absence of any continuously measure **** [NOTE] -Only metrics that fulfil certain criteria are exported by the <>. Please refer to <> and <> for further information. +Only metrics that fulfil certain criteria are exported by the <>. Please refer to <> and <> for further information. @@ -394,14 +394,14 @@ Only metrics that fulfil certain criteria are exported by the <> may set the OBR-8 field to the end date and time of the current export interval. +A <> may set the OBR-8 field to the end date and time of the current export interval. ==== [NOTE] ==== * This requirement relates to the OBR-7 field mapping. Please refer to <> for further information. -* 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. +* 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. ==== **** @@ -414,7 +414,7 @@ A <> may set the OBR-8 field to the end date and time o **** [NORMATIVE] ==== -A <> shall set the OBR-10 field to the operator (user) information if available. +A <> shall set the OBR-10 field to the operator (user) information if available. The field is left empty if there is no valid SDC operator context. ==== @@ -497,7 +497,7 @@ Please refer to the <> *OBX-1 Set ID - OBX* for further i **** [NORMATIVE] ==== -A <> shall set the OBX-2 field to the metric value type code as defined in *HL7 table 0125*. +A <> shall set the OBX-2 field to the metric value type code as defined in *HL7 table 0125*. ==== [NOTE] @@ -511,7 +511,7 @@ A <> shall set the OBX-2 field to the metric value type **** [NORMATIVE] ==== -A <> shall leave the OBX-2 field empty for OBX segments defining the <>'s MDS, VMD, or CHAN containment tree elements. +A <> shall leave the OBX-2 field empty for OBX segments defining the <>'s MDS, VMD, or CHAN containment tree elements. ==== **** @@ -547,7 +547,7 @@ Please refer to general Section <>. **** [NORMATIVE] ==== -A <> shall set the OBX-5 field to the value of the SDC metric. +A <> shall set the OBX-5 field to the value of the SDC metric. ==== [NOTE] @@ -570,7 +570,7 @@ For a device-related element such as MDS, VMD, or channel, the OBX-5 field shall **** [NORMATIVE] ==== -A <> shall only export metrics with a *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to *Vld* (Valid) or *Vldated* (Validated Data). +A <> shall only export metrics with a *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to *Vld* (Valid) or *Vldated* (Validated Data). ==== [NOTE] @@ -584,7 +584,7 @@ Metrics with a different *@Validity* are skipped/ignored. **** [NORMATIVE] ==== -A <> shall only export metrics with the *pm:AbstractMetricDescriptor/@MetricCategory* set to *Msrmt* (Measurement), *Clc* (Calculation) or *Set* (Setting). +A <> shall only export metrics with the *pm:AbstractMetricDescriptor/@MetricCategory* set to *Msrmt* (Measurement), *Clc* (Calculation) or *Set* (Setting). ==== [NOTE] @@ -601,14 +601,14 @@ Metrics with a different *@MetricCategory* are skipped/ignored. **** [NORMATIVE] ==== -For each numeric metric that complies with <> and <>, a <> shall set the OBX-5 field to the *pm:NumericMetricState/pm:MetricValue/@Value*. +For each numeric metric that complies with <> and <>, a <> shall set the OBX-5 field to the *pm:NumericMetricState/pm:MetricValue/@Value*. ==== [NOTE] ==== * Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules. -* Note that sample array metrics are not supported by the <>. +* Note that sample array metrics are not supported by the <>. ==== **** @@ -619,7 +619,7 @@ For each numeric metric that complies with <> and <>, a <> shall set the OBX-5 field to the *pm:StringMetricState/pm:MetricValue/@Value*. +For each string metric that complies with R8017 and R8018, a <> shall set the OBX-5 field to the *pm:StringMetricState/pm:MetricValue/@Value*. ==== **** @@ -631,7 +631,7 @@ For each string metric that complies with R8017 and R8018, a <> shall set the OBX-5 field to a coded element value. +For each enumeration string metric that complies with R8017 and R8018, a <> shall set the OBX-5 field to a coded element value. ==== [NOTE] @@ -653,7 +653,7 @@ the OBX-2 is required to be set to *"ST"* (see also <> **** [NORMATIVE] ==== -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 <>. ==== **** @@ -696,7 +696,7 @@ In all other cases, the field is set to pm:EnumStringMetricDescriptor+++++ **** [NORMATIVE] ==== -For each numeric metric, a <> shall set the OBX-6 field to a measurement unit. +For each numeric metric, a <> shall set the OBX-6 field to a measurement unit. ==== [NOTE] @@ -712,7 +712,7 @@ For each numeric metric, a <> shall set the OBX-6 field **** [NORMATIVE] ==== -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 <>. ==== **** @@ -755,7 +755,7 @@ In all other cases, the field is set to pm:NumericMetricDescriptor++++++/p **** [NORMATIVE] ==== -A <> shall define the range of the alert limits on the metric level, if the *@Handle* of the metric is referenced by a *pm:LimitAlertConditionDescriptor* in the *pm:LimitAlertConditionDescriptor/pm:Source* list, by the format ` - ` where +A <> shall define the range of the alert limits on the metric level, if the *@Handle* of the metric is referenced by a *pm:LimitAlertConditionDescriptor* in the *pm:LimitAlertConditionDescriptor/pm:Source* list, by the format ` - ` where * `` is set to *pm:LimitAlertConditionState/pm:Limits/@Lower* and * `` is set to *pm:LimitAlertConditionState/pm:Limits/@Upper*. @@ -772,7 +772,7 @@ Note that the decimal number needs to be formatted according to the HL7 numeric **** [NORMATIVE] ==== -A <> shall not set this field to the device measurement range capability for device related segments. +A <> shall not set this field to the device measurement range capability for device related segments. ==== [NOTE] @@ -790,7 +790,7 @@ The OBX-8 field is not required to be set since the gateway exports valid and va **** [NORMATIVE] ==== -A <> shall leave the OBX-8 field empty as specified in the <> for valid and validated metric values. +A <> shall leave the OBX-8 field empty as specified in the <> for valid and validated metric values. ==== **** @@ -801,7 +801,7 @@ A <> shall leave the OBX-8 field empty as specified in **** [NORMATIVE] ==== -For a device-related element such as MDS, VMD, or CHANNEL, a <> shall set the OBX-11 field to *"X"*. +For a device-related element such as MDS, VMD, or CHANNEL, a <> shall set the OBX-11 field to *"X"*. ==== **** @@ -810,7 +810,7 @@ For a device-related element such as MDS, VMD, or CHANNEL, a <> shall set the OBX-11 field to *"R"*. +For metrics with the *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to *Vld* (Valid), a <> shall set the OBX-11 field to *"R"*. ==== **** @@ -819,7 +819,7 @@ For metrics with the *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to **** [NORMATIVE] ==== -For metrics with the *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to *Vldated* (Validated Data), a <> shall set the OBX-11 field to *"F"*. +For metrics with the *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to *Vldated* (Validated Data), a <> shall set the OBX-11 field to *"F"*. ==== **** @@ -830,7 +830,7 @@ For metrics with the *pm:AbstractMetricValue/pm:MetricQuality/@Validity* set to **** [NORMATIVE] ==== -A <> shall set the OBX-14 field to the date and time of the intermittently measured metric value. +A <> shall set the OBX-14 field to the date and time of the intermittently measured metric value. ==== [NOTE] @@ -864,7 +864,7 @@ pm:StringMetricState++++++/pm:MetricValue++++++/@DeterminationTime **** [NORMATIVE] ==== -If available, a <> shall set the OBX-16 field to the operator. +If available, a <> shall set the OBX-16 field to the operator. ==== [NOTE] @@ -882,7 +882,7 @@ If available, a <> shall set the OBX-16 field to the op **** [NORMATIVE] ==== -A <> shall set the OBX-17 field to one of the coded terms as specified in <>, depending on the *pm:AbstractMetricDescriptor/@MetricCategory* (Category) and the *pm:AbstractMetricDescriptor/@DerivationMethod* (Derivation). +A <> shall set the OBX-17 field to one of the coded terms as specified in <>, depending on the *pm:AbstractMetricDescriptor/@MetricCategory* (Category) and the *pm:AbstractMetricDescriptor/@DerivationMethod* (Derivation). ==== **** @@ -891,7 +891,7 @@ A <> shall set the OBX-17 field to one of the coded ter **** [NORMATIVE] ==== -A <> should repeat the OBX-17 field to express the *pm:AbstractMetricDescriptor/@MetricAvailability* as specified in <>. +A <> should repeat the OBX-17 field to express the *pm:AbstractMetricDescriptor/@MetricAvailability* as specified in <>. ==== **** @@ -949,7 +949,7 @@ Please refer to general Section <>. **** [NORMATIVE] ==== -If available for the metric, a <> shall set the OBX-20 field to body site. +If available for the metric, a <> shall set the OBX-20 field to body site. ==== [NOTE] @@ -969,7 +969,7 @@ If available for the metric, a <> shall set the OBX-20 **** [NORMATIVE] ==== -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 <>. ==== **** diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc index 58cb028c..c7883851 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-fhir.adoc @@ -3,7 +3,7 @@ ==== 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 <> 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. diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-msh-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-msh-mapping.adoc index 1f69cab3..9396e02c 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-msh-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-msh-mapping.adoc @@ -31,7 +31,7 @@ The HL7 segments *MSH*, *PID*, and *PV1* contain information which can differ be **** [NORMATIVE] ==== -A <> / <> shall set the MSH-11 field to the code for the processing ID, which is either be *"P"* (Production) or *"D"* (Debugging). +A <> / <> shall set the MSH-11 field to the code for the processing ID, which is either be *"P"* (Production) or *"D"* (Debugging). ==== [NOTE] diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx18-mapping.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx18-mapping.adoc index 1514d9fc..723c8284 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx18-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx18-mapping.adoc @@ -6,7 +6,7 @@ **** [NORMATIVE] ==== -A <> / <> shall set the OBX-18 field to the equipment (or device) identifier on the MDS level and/or the measurement module identifier of the equipment on the VMD level as defined in section <>. +A <> / <> shall set the OBX-18 field to the equipment (or device) identifier on the MDS level and/or the measurement module identifier of the equipment on the VMD level as defined in section <>. ==== [NOTE] 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 81080b52..9142fc2e 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx3-mapping.adoc @@ -7,7 +7,7 @@ [NORMATIVE] ==== -A <> / <> shall set the OBX-3 field to the identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric to be exported. +A <> / <> shall set the OBX-3 field to the identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric to be exported. ==== [NOTE] @@ -22,7 +22,7 @@ A <> / <> shall set the OBX-3 **** [NORMATIVE] ==== -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 <>. +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 <>. ==== **** 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 3a3f06d3..6a44f528 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-obx4-mapping.adoc @@ -6,7 +6,7 @@ **** [NORMATIVE] ==== -A <> / <> shall set the OBX-4 field to a hierarchical representation of the SDC element in the hierarchical containment tree. +A <> / <> shall set the OBX-4 field to a hierarchical representation of the SDC element in the hierarchical containment tree. ==== [NOTE] @@ -20,7 +20,7 @@ Please refer to the IHE technical framework <> for furthe **** [NORMATIVE] ==== -A <> / <> shall assign the handles (which are required to be unique in the same <>) of the containment tree elements representing MDSs, VMDs, channels and metrics to unique integer numbers per child level of the same parent. +A <> / <> shall assign the handles (which are required to be unique in the same <>) of the containment tree elements representing MDSs, VMDs, channels and metrics to unique integer numbers per child level of the same parent. ==== [NOTE] 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 5c83ebdf..85924ff3 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pid-mapping.adoc @@ -14,7 +14,7 @@ The SDC patient context information shall only be mapped to the corresponding fi [NOTE] ==== -* For a valid *pm:PatientContextState*, the *pm:AbstractContextState/@ContextAssociation* attribute is set to *"Assoc"* and the *pm:AbstractContextState/pm:Validator* is set to a valid validator. A corresponding inferred patient ensemble context is not required for the <> / <>. +* For a valid *pm:PatientContextState*, the *pm:AbstractContextState/@ContextAssociation* attribute is set to *"Assoc"* and the *pm:AbstractContextState/pm:Validator* is set to a valid validator. A corresponding inferred patient ensemble context is not required for the <> / <>. * If the SDC patient context information is not intended to be used for the mapping, please refer to the <> on how to populate the fields of the PID segment in this case. ==== @@ -26,7 +26,7 @@ The SDC patient context information shall only be mapped to the corresponding fi **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall map the patient identifiers to the PID-3 field. +If <> is met, then a <> / <> shall map the patient identifiers to the PID-3 field. ==== [NOTE] @@ -100,7 +100,7 @@ The following identifier type codes are proposed to be used for the patient iden **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall set the PID-5 field to the patient name information. +If <> is met, then a <> / <> shall set the PID-5 field to the patient name information. ==== [NOTE] @@ -154,7 +154,7 @@ Please refer also to the corresponding section in the <>. **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall set the PID-6 field to the mother's maiden name or birth name before marriage. +If <> is met, then a <> / <> shall set the PID-6 field to the mother's maiden name or birth name before marriage. ==== [NOTE] @@ -186,7 +186,7 @@ If <> is met, then a <> / <> is met, then a <> / <> shall set the PID-7 field to the date and time of birth. +If <> is met, then a <> / <> shall set the PID-7 field to the date and time of birth. ==== [NOTE] @@ -228,7 +228,7 @@ Mappings to the *PID-8 Administrative Sex* field are allowed in certain cases as **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall export the patient's sex as OBX segment on the MDS level. +If <> is met, then a <> / <> shall export the patient's sex as OBX segment on the MDS level. ==== [NOTE] @@ -242,7 +242,7 @@ The mapping for the patient's sex is defined in table <> is met and the patient's sex in the <> is sourced from the PID-8 field in HL7 V2 ADT messages provided by the hospital ADT system, then a <> / <> may set the PID-8 field to the code for the administrative sex. +If <> is met and the patient's sex in the <> is sourced from the PID-8 field in HL7 V2 ADT messages provided by the hospital ADT system, then a <> / <> may set the PID-8 field to the code for the administrative sex. ==== [NOTE] @@ -256,7 +256,7 @@ If <> is met and the patient's sex in the <> is sourced fro **** [NORMATIVE] ==== -If <> is met and the <> provides the Healthcare Delivery Organization (HDO) the possibility to configure the export of the patient's sex set in the <> in the PID-8 field, then a <> / <> shall set the PID-8 field to the code for the administrative sex. +If <> is met and the <> provides the Healthcare Delivery Organization (HDO) the possibility to configure the export of the patient's sex set in the <> in the PID-8 field, then a <> / <> shall set the PID-8 field to the code for the administrative sex. ==== [NOTE] @@ -270,7 +270,7 @@ If <> is met and the <> provides the Healthcare D **** [NORMATIVE] ==== -If the <> provides the Healthcare Delivery Organization (HDO) the possibility to configure the export of the patient's sex in the PID-8 field, the manufacturer of the <> shall require in the ACCOMPANYING INFORMATION that the HDO has to consider the risk that the patient's sex set in the <> and mapped to the PID-8 field does not lead to a misinterpretation of the sex concept on <> consumer side. +If the <> provides the Healthcare Delivery Organization (HDO) the possibility to configure the export of the patient's sex in the PID-8 field, the manufacturer of the <> shall require in the ACCOMPANYING INFORMATION that the HDO has to consider the risk that the patient's sex set in the <> and mapped to the PID-8 field does not lead to a misinterpretation of the sex concept on <> consumer side. ==== **** @@ -377,7 +377,7 @@ When there are further updates of the sex value after the association of the pat **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall set the PID-10 field to the patient's race. +If <> is met, then a <> / <> shall set the PID-10 field to the patient's race. ==== [NOTE] @@ -441,7 +441,7 @@ If <> is met, then a <> / <> is met, then a <> / <> shall set the PID-31 field to an indicator whether the patient's identity is known. +If <> is met, then a <> / <> shall set the PID-31 field to an indicator whether the patient's identity is known. ==== [NOTE] @@ -450,6 +450,6 @@ If <> is met, then a <> / <> / <> in order to determine a valid *pm:PatientContextState*. +* A corresponding inferred patient ensemble context is not required for the <> / <> in order to determine a valid *pm:PatientContextState*. ==== **** 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 580ca3c9..ae1a0bb4 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-pv1-mapping.adoc @@ -14,7 +14,7 @@ The SDC patient and location context information shall only be mapped to the cor [NOTE] ==== -* For a valid *pm:PatientContextState* or *pm:LocationContextSate*, the *pm:AbstractContextState/@ContextAssociation* attribute is set to *"Assoc"* and the *pm:AbstractContextState/pm:Validator* is set to a valid validator. A corresponding inferred patient or location ensemble context is not required for the <> / <>. +* For a valid *pm:PatientContextState* or *pm:LocationContextSate*, the *pm:AbstractContextState/@ContextAssociation* attribute is set to *"Assoc"* and the *pm:AbstractContextState/pm:Validator* is set to a valid validator. A corresponding inferred patient or location ensemble context is not required for the <> / <>. * If the SDC patient and/or location context information is not be used for the mapping, please refer to the <> on how to populate the fields of the PV1 segment in this case. ==== @@ -26,7 +26,7 @@ The SDC patient and location context information shall only be mapped to the cor **** [NORMATIVE] ==== -A <> / <> shall set the PV1-2 field to the code for the patient class. +A <> / <> shall set the PV1-2 field to the code for the patient class. ==== [NOTE] @@ -45,7 +45,7 @@ The SDC data model does not support the concept of a patient class. Therefore, t **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall set the PV1-3 field to the patient's assigned location. +If <> is met, then a <> / <> shall set the PV1-3 field to the patient's assigned location. ==== [NOTE] @@ -102,7 +102,7 @@ If <> is met, then a <> / <> is met, then a <> / <> shall set the PV1-19 field to the patient's visit identifier. +If <> is met, then a <> / <> shall set the PV1-19 field to the patient's visit identifier. If the SDC patient identifier element *pm:PatientContextState/pm:Identification* contains more than one patient identifier, only the unique identifier assigned to the patient's visit is mapped according to the <> table. @@ -156,14 +156,14 @@ Valid *"Identifier Type Code"* values for a visit number are, for example, *"VN" **** [NORMATIVE] ==== -If <> is met, then a <> / <> shall set the PV1-44 field to the patient's admission date/time. +If <> is met, then a <> / <> shall set the PV1-44 field to the patient's admission date/time. ==== [NOTE] ==== 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. +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. ==== **** @@ -173,7 +173,7 @@ This said, it is up to the <> / <> is met, then a <> / <> shall set the PV1-51 field to the code for the visit indicator. +If <> is met, then a <> / <> shall set the PV1-51 field to the code for the visit indicator. If *"pm:PatientContextState/pm:Identification/pm:Type/@Code"* is "VN" (Visit Number), the field is set to *"V"*. diff --git a/asciidoc/volume2/gateways/tf2-ch-b-gateway-v2.adoc b/asciidoc/volume2/gateways/tf2-ch-b-gateway-v2.adoc index 48676d83..88dbb257 100644 --- a/asciidoc/volume2/gateways/tf2-ch-b-gateway-v2.adoc +++ b/asciidoc/volume2/gateways/tf2-ch-b-gateway-v2.adoc @@ -10,7 +10,7 @@ NOTE: As stated in <> all observation times reported SHOU NOTE: If the timestamps are to be specified in local time, it is important that the time zone is set correctly at the <>. -NOTE: It is not always guaranteed that the timezone configured at the <> and/or <> / <> corresponds with the timezone of the <> entities, for example, when a <> acting as device aggregator and/or the <> / <> are running in a data center located in a different timezone than the <> entities. +NOTE: It is not always guaranteed that the timezone configured at the <> and/or <> / <> corresponds with the timezone of the <> entities, for example, when a <> acting as device aggregator and/or the <> / <> are running in a data center located in a different timezone than the <> entities. ==== diff --git a/asciidoc/volume2/mdib-report-retrofit/tf2-ch-a-mdpws-mdib-report-retrofit.adoc b/asciidoc/volume2/mdib-report-retrofit/tf2-ch-a-mdpws-mdib-report-retrofit.adoc index 4f82b468..f5978f87 100644 --- a/asciidoc/volume2/mdib-report-retrofit/tf2-ch-a-mdpws-mdib-report-retrofit.adoc +++ b/asciidoc/volume2/mdib-report-retrofit/tf2-ch-a-mdpws-mdib-report-retrofit.adoc @@ -149,12 +149,12 @@ A <> that receives multiple reports with **** [NORMATIVE] ==== -A <> shall not send a notification of a subscription as long as there is another notification pending for that subscription. +A <> shall not send a notification of a subscription as long as there is another notification pending for that subscription. ==== [NOTE] ==== -This also requires <>s to serialize delivery of msg:OperationInvokedReport messages. +This also requires <>s to serialize delivery of msg:OperationInvokedReport messages. ==== **** diff --git a/asciidoc/volume2/tf2-ch-a-mdpws.adoc b/asciidoc/volume2/tf2-ch-a-mdpws.adoc index 60b07f52..427e2c49 100644 --- a/asciidoc/volume2/tf2-ch-a-mdpws.adoc +++ b/asciidoc/volume2/tf2-ch-a-mdpws.adoc @@ -4,7 +4,7 @@ [CAUTION] ==== Message outlines do not contain information regarding required/optional elements/attributes nor cardinalities. -In order to produce valid messages, the implementation of a <> needs to conform to the +In order to produce valid messages, the implementation of a <> needs to conform to the referenced standards of which the message outlines herein were generated. ==== diff --git a/asciidoc/volume2/tf2-ch-c-security.adoc b/asciidoc/volume2/tf2-ch-c-security.adoc index 2b2bbdf3..2351a540 100644 --- a/asciidoc/volume2/tf2-ch-c-security.adoc +++ b/asciidoc/volume2/tf2-ch-c-security.adoc @@ -14,7 +14,7 @@ [cols="1"] |=== -a| *{supplement_note}*: This Security Management appendix provides a single location within the SDPi technical specifications to describe and discuss topics related to SDC and related security needs, risks and controls. Anticipated content in future SDPi versions will include: +a| *{standard_note}*: This Security Management appendix provides a single location within the SDPi technical specifications to describe and discuss topics related to SDC and related security needs, risks and controls. Anticipated content in future SDPi versions will include: * *Approaches*: Use of the security provisions in the current IEEE 11073 SDC core standards (esp. 11073-20702), as well as next generation SDC security approaches under development, rationale behind each, and how the various approaches can co-exist ... or not; * *Extensions*: Additional specifications may be included, such as the formatting for an Allow/Deny list and when it might be used. diff --git a/asciidoc/volume2/tf2-main.adoc b/asciidoc/volume2/tf2-main.adoc index 68936aaf..b7051294 100644 --- a/asciidoc/volume2/tf2-main.adoc +++ b/asciidoc/volume2/tf2-main.adoc @@ -120,7 +120,7 @@ include::dev-49/tf2-dev-49.adoc[] // TODO https://confluence.hl7.org/display/GP/Topic%3A+Connect+Time+Delay+Algorithm // -//NOTE: This document integrates all the content that makes up the supplement volume 2 document. +//NOTE: This document integrates all the content that makes up the standard volume 2 document. // //IMPORTANT: Migrate the content below from main.adoc into this document OR rename main.adoc to this ... though the content is different. + //{empty} + diff --git a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.7-compound-metric-modelling.adoc b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.7-compound-metric-modelling.adoc index 1976561b..bbb2f5ad 100644 --- a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.7-compound-metric-modelling.adoc +++ b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.7-compound-metric-modelling.adoc @@ -35,7 +35,7 @@ This section defines the requirements to compound metrics provided in the MDIB d **** [NORMATIVE] ==== -For each compound metric, the <> shall provide a *pm:Relation* element to relate to all metrics belonging to the same compound metric. +For each compound metric, the <> shall provide a *pm:Relation* element to relate to all metrics belonging to the same compound metric. ==== **** @@ -44,7 +44,7 @@ For each compound metric, the <> shall provide a *pm:Relat **** [NORMATIVE] ==== -For each *pm:Relation* of a <> that expresses membership in a compound metric, the <> shall set *pm:Code* to the coded term of the compound metric it belongs to. +For each *pm:Relation* of a <> that expresses membership in a compound metric, the <> shall set *pm:Code* to the coded term of the compound metric it belongs to. ==== **** @@ -53,7 +53,7 @@ For each *pm:Relation* of a <> that expresses membership i **** [NORMATIVE] ==== -For each *pm:Relation* of a <> that expresses membership in a compound metric, the <> shall set *@Kind* to *SST*. +For each *pm:Relation* of a <> that expresses membership in a compound metric, the <> shall set *@Kind* to *SST*. ==== **** @@ -62,7 +62,7 @@ For each *pm:Relation* of a <> that expresses membership i **** [NORMATIVE] ==== -For each *pm:Relation* of a <> that expresses membership in a compound metric, the <> shall include all handle references of those metrics that belong to the same compound metric in *pm:Relation/@Entries* excluding the handle of the metric that contains the *pm:Relation*. +For each *pm:Relation* of a <> that expresses membership in a compound metric, the <> shall include all handle references of those metrics that belong to the same compound metric in *pm:Relation/@Entries* excluding the handle of the metric that contains the *pm:Relation*. ==== **** @@ -74,7 +74,7 @@ For each *pm:Relation* of a <> that expresses membership i **** [NORMATIVE] ==== -For each compound metric of a <>, if *@StartTime* and *@StopTime* are available, the <> shall provide the same values for *@StartTime* and *@StopTime* in each metric of the compound metric to signify the same measurement cycle. +For each compound metric of a <>, if *@StartTime* and *@StopTime* are available, the <> shall provide the same values for *@StartTime* and *@StopTime* in each metric of the compound metric to signify the same measurement cycle. ==== [NOTE] @@ -88,6 +88,6 @@ For each compound metric of a <>, if *@StartTime* and *@St **** [NORMATIVE] ==== -For each compound metric of a <>, if *@StartTime* and *@StopTime* are not available, the <> shall provide the same value for *@DeterminationTime* in each metric of the compound metric to signify the same measurement cycle. +For each compound metric of a <>, if *@StartTime* and *@StopTime* are not available, the <> shall provide the same value for *@DeterminationTime* in each metric of the compound metric to signify the same measurement cycle. ==== **** \ No newline at end of file diff --git a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.8-localized-text-catalog-identification.adoc b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.8-localized-text-catalog-identification.adoc index c771b240..59480e7a 100644 --- a/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.8-localized-text-catalog-identification.adoc +++ b/asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.8-localized-text-catalog-identification.adoc @@ -6,7 +6,7 @@ In <>, localized texts for parameter labels, alert strings, enum Text references are unique within a device scope. However, <> vendors typically use the same text strings and text references for several of their products. -In order to reduce the effort for a <> for managing individual lookup tables per <>, a lookup table that resolves the text references for multiple <> from the same <> vendor is desirable for a <>. +In order to reduce the effort for a <> for managing individual lookup tables per <>, a lookup table that resolves the text references for multiple <> from the same <> vendor is desirable for a <>. The set of all localized text strings with their unique text reference and language code is referred to as "*TEXT CATALOG*" in the following paragraphs. When localized text strings have been added, changed, or deleted in the *TEXT CATALOG*, this is considered as a new version of the *TEXT CATALOG*. @@ -14,14 +14,14 @@ The following best practices are highly recommended when using *TEXT CATALOGS*: .Recommendation A **** -A <> that has implemented the *<> LOCALIZATION SERVICE* is supposed to provide a unique *TEXT CATALOG* identifier in the *pm:MdsDescriptor++++++/pm:ProductionSpecification* list with *pm:ProductionSpecification++++++/pm:SpecType++++++/@Code = 68008 (MDC_ATTR_VMS_MDS_TEXT_CAT)*. +A <> that has implemented the *<> LOCALIZATION SERVICE* is supposed to provide a unique *TEXT CATALOG* identifier in the *pm:MdsDescriptor++++++/pm:ProductionSpecification* list with *pm:ProductionSpecification++++++/pm:SpecType++++++/@Code = 68008 (MDC_ATTR_VMS_MDS_TEXT_CAT)*. NOTE: The unique *TEXT CATALOG* identifier defined in the corresponding *pm:ProductionSpecification++++++/pm:ProductionSpec* can be a URN of type *uuid* or *oid*, e. g. *"urn:oid:1.3.6.1.4.1.1234.4.1.2.1"*. **** .Recommendation B **** -A <> that has implemented the *<> LOCALIZATION SERVICE* and supports explicit versioning of the *TEXT CATALOG* is supposed to provide a URN that includes the unique version number as part of the unique *TEXT CATALOG* identifier in the *pm:MdsDescriptor++++++/ProductionSpecification++++++/pm:ProductionSpec*. +A <> that has implemented the *<> LOCALIZATION SERVICE* and supports explicit versioning of the *TEXT CATALOG* is supposed to provide a URN that includes the unique version number as part of the unique *TEXT CATALOG* identifier in the *pm:MdsDescriptor++++++/ProductionSpecification++++++/pm:ProductionSpec*. NOTE: "_urn:oid:1.3.6.1.4.1.1234.4.1.2_.*1.2.2*" is an example of a unique *TEXT CATALOG* id with the *TEXT CATALOG* version "*1.2.2*" added as additional nodes to the OID. @@ -30,7 +30,7 @@ NOTE: If the version number is already part of the unique *TEXT CATALOG* identif .Recommendation C **** -A <> that provides a unique *TEXT CATALOG* identifier in the *pm:MdsDescriptor++++++/pm:ProductionSpecification* needs to ensure that the unique *TEXT CATALOG* identifier is updated when the *TEXT CATALOG* has changed (e. g. due to a firmware update of device with modified localized text strings). +A <> that provides a unique *TEXT CATALOG* identifier in the *pm:MdsDescriptor++++++/pm:ProductionSpecification* needs to ensure that the unique *TEXT CATALOG* identifier is updated when the *TEXT CATALOG* has changed (e. g. due to a firmware update of device with modified localized text strings). NOTE: It is also important to ensure that the unique *TEXT CATALOG* identifier is not the same as a *TEXT CATALOG* identifier from a previous version of the *TEXT CATALOG*. **** \ No newline at end of file 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 66881d5c..aafb924b 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 @@ -5,7 +5,7 @@ [%autowidth] [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. +a| *{standard_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 and gender harmonization policy will be taken in this and future SDPi specification versions until clear direction is available. [none] diff --git a/asciidoc/volume3/mdib-efficiency/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 index 0b047a12..c810fedc 100644 --- a/asciidoc/volume3/mdib-efficiency/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 @@ -18,7 +18,7 @@ The <> should be modelled in a minimalistic way, which results in Low-frequent @DeterminationPeriod:: Determination periods of metrics should be short enough such that data remains clinically relevant when transmitted, but long enough such that data transmission does not cause high processor and network load. -Metrics having a common @DeterminationPeriod:: This allows for the <> to collect updates in a single metric report instead of clustering updates across many metric reports. +Metrics having a common @DeterminationPeriod:: This allows for the <> to collect updates in a single metric report instead of clustering updates across many metric reports. Waveforms having a common @DeterminationPeriod:: Real-time sample array metrics are used to model waveforms and are distributed by using the BICEPS WAVEFORM service. Analogous to other metric types, real-time sample array metrics should also share the same @DeterminationPeriod. 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 a806f868..4579f7a0 100644 --- a/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc +++ b/asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc @@ -3,7 +3,7 @@ [#vol3_clause_sdc_biceps_semantic_content_module] ===== SDC/BICEPS Content Module -The <> standard, <>, provides an extensive semantic model for all information exchanged between <> systems. This section provides a general background for <>-based content, including both what is unique to this standard (e.g., different from the <>), and any extensions that are made by this SDPi supplement. +The <> standard, <>, provides an extensive semantic model for all information exchanged between <> systems. This section provides a general background for <>-based content, including both what is unique to this standard (e.g., different from the <>), and any extensions that are made by this SDPi standard. .R0701 @@ -55,12 +55,12 @@ NOTE: A detailed description of this <> description information [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This version of the supplement does not fully support profiles of all the elements in the descriptive model, including: +a| *{standard_note}*: This version of the standard does not fully support profiles of all the elements in the descriptive model, including: * Service Control Object (SCO) and Operations * Battery objects -Additionally, only limited support for the *_AlertSystem_* (and related objects), and for the *_SystemContext_* types are provided in SDPi {ihe_supplement_sdpi_revision_short}. +Additionally, only limited support for the *_AlertSystem_* (and related objects), and for the *_SystemContext_* types are provided in SDPi {gemini_standard_sdpi_revision_short}. Subsequent versions of the specification will address complete functionality. |=== @@ -78,7 +78,7 @@ The basic containment from MDS to VMD to Channel to Metric is maintained within [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This clause is intentionally left blank for this version. +a| *{standard_note}*: This clause is intentionally left blank for this version. Future versions will include general discussion about how BICEPS-based content is formally mapped to that of other protocols, typically utilizing a <>. |=== @@ -206,7 +206,7 @@ This includes OIDs for private codes as detailed in < [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The <> 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_]. +a| *{standard_note}*: The <> 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. For this version of the specification, the following wording has been suggested: diff --git a/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc b/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc index 993d6915..075c649c 100644 --- a/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc +++ b/asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc @@ -1,7 +1,7 @@ [#vol3_clause_metric_display_precision] ===== Numeric Metric Display Precision -A <> conforming to the <>, provides numeric metric data that fulfils the following requirements: +A <> conforming to the <>, provides numeric metric data that fulfils the following requirements: [quote, "TR0239"] ____ @@ -40,22 +40,22 @@ If the metric *@Value* falls in one of the *pm:TechnicalRange* elements and in o *For Metric @Samples*: -For metric *@Samples*, it is possible that individual samples fall in different *pm:TechnicalRange* or *pm:PhysiologicalRange* elements. In this case the <> has to decide which of the *pm:TechnicalRange* or *pm:PhysiologicalRange* element is considered as the _active range_ (*pm:Range* element) for the entire set of samples currently utilized for displaying - e.g., *Airway Pressure* wave displayed with the highest precision defined by the _active range_ at the consumer's screen. +For metric *@Samples*, it is possible that individual samples fall in different *pm:TechnicalRange* or *pm:PhysiologicalRange* elements. In this case the <> has to decide which of the *pm:TechnicalRange* or *pm:PhysiologicalRange* element is considered as the _active range_ (*pm:Range* element) for the entire set of samples currently utilized for displaying - e.g., *Airway Pressure* wave displayed with the highest precision defined by the _active range_ at the consumer's screen. If an individual sample falls in one of the *pm:TechnicalRange* elements and in one of *pm:PhysiologicalRange* elements at the same time, the *pm:PhysiologicalRange* element of the metric state will supersede the *pm:TechnicalRange* element of the descriptor and will become the _active range_ for this particular sample. ====== When to define the *mpkp:DisplayPrecision* extension? -As already defined in *TR0242* of the <> standard, the <> is required to provide a *mpkp:DisplayPrecision* extension when the metric's *@Resolution* differs from the metric's display precision. The *mpkp:DisplayPrecision* extension must also be provided when the metric's *@StepWidth* of the _active range_ differs from the *@Resolution* - independently of the metric's display precision. This part of the requirement will be changed in a future version of the standard, so that the <> is only required to provide a *mpkp:DisplayPrecision* extension when the metric's *@StepWidth* of the _active range_ *also* differs from the metric's display precision. Otherwise, the metric's *@StepWidth* of the _active range_ defines the metric's display precision. +As already defined in *TR0242* of the <> standard, the <> is required to provide a *mpkp:DisplayPrecision* extension when the metric's *@Resolution* differs from the metric's display precision. The *mpkp:DisplayPrecision* extension must also be provided when the metric's *@StepWidth* of the _active range_ differs from the *@Resolution* - independently of the metric's display precision. This part of the requirement will be changed in a future version of the standard, so that the <> is only required to provide a *mpkp:DisplayPrecision* extension when the metric's *@StepWidth* of the _active range_ *also* differs from the metric's display precision. Otherwise, the metric's *@StepWidth* of the _active range_ defines the metric's display precision. -While *TR0800* is a SHOULD requirement and the *@StepWidth* for a particular *pm:Range* element might not be defined, *TR0242* mandates the <> to provide a *mpkp:DisplayPrecision* extension when the metric's *@Resolution* differs from the display precision. +While *TR0800* is a SHOULD requirement and the *@StepWidth* for a particular *pm:Range* element might not be defined, *TR0242* mandates the <> to provide a *mpkp:DisplayPrecision* extension when the metric's *@Resolution* differs from the display precision. .Ventilator Minute Volume Parameter Representation ==== A ventilator measures the *Minute Volume (MV)* in *L/min* with a resolution of one decimal place, but dependent on the value, the number is either displayed with no or one decimal place. -The <> defines the following in the *pm:NumericMetricDescriptor* of the *MV* metric: +The <> defines the following in the *pm:NumericMetricDescriptor* of the *MV* metric: * *@Resolution* = "0.1" * *pm:TechnicalRange[0]/@Upper* = "100.0" @@ -68,10 +68,10 @@ The <> defines the following in the *pm:NumericMetricDescr The first range is defined from *10.0 L/min* to *100.0 L/min*. The measurement precision stays the same (*@Resolution* and *@StepWidth* are identical). -However, the <> indicates to the <> that the *MV* parameter value needs to be displayed with no decimal places (*mpkp:DisplayPrecision/@StepWidth* = "1"). +However, the <> indicates to the <> that the *MV* parameter value needs to be displayed with no decimal places (*mpkp:DisplayPrecision/@StepWidth* = "1"). The second range is defined from *0.0 L/min* to *9.9 L/min*. -Since there is no specific display precision defined, the <> knows that the *MV* parameter value needs to be displayed with one decimal places (*@StepWidth* = "0.1"). +Since there is no specific display precision defined, the <> knows that the *MV* parameter value needs to be displayed with one decimal places (*@StepWidth* = "0.1"). Note that if the *@StepWidth* in the second range was not defined, the precision of the *@Resolution* would also define display precision. @@ -101,7 +101,7 @@ However, this does not apply for the zeros _before_ the decimal point. In this c **** [NORMATIVE] ==== -A <> shall determine the _active range_ for the current metric's *@Value* or a set of multiple metric's *@Samples* to be displayed at the <>'s display by the following priority order: +A <> shall determine the _active range_ for the current metric's *@Value* or a set of multiple metric's *@Samples* to be displayed at the <>'s display by the following priority order: . The *pm:PhysiologicalRange* element of the metric state where the current metric's *@Value* or a sample that represents the display precision for the entire set of metric's *@Samples* falls into. . The *pm:TechnicalRange* element of the metric descriptor where the current metric's *@Value* or a sample that represents the display precision for the entire set of metric's *@Samples* falls into. @@ -109,7 +109,7 @@ A <> shall determine the _active range_ for the current me [NOTE] ==== -If the <> wants to display, for example, a wave on the screen which consists of samples from multiple metric's *@Samples*, the display precision of the wave must be determined from the display precision of the individual samples. It is then up to the <> to select a common display precision for all samples to be displayed at the screen as a wave. +If the <> wants to display, for example, a wave on the screen which consists of samples from multiple metric's *@Samples*, the display precision of the wave must be determined from the display precision of the individual samples. It is then up to the <> to select a common display precision for all samples to be displayed at the screen as a wave. ==== **** @@ -118,7 +118,7 @@ If the <> wants to display, for example, a wave on the scr **** [NORMATIVE] ==== -A <> shall determine the current display precision for a metric's *@Value* or *@Samples* by the following priority order: +A <> shall determine the current display precision for a metric's *@Value* or *@Samples* by the following priority order: 1. *ext:Extension/mpkp:DisplayPrecision/@StepWidth* is defined for the _active range_ 2. *pm:Range/@StepWidth* is defined for the _active range_ diff --git a/asciidoc/volume3/tf3-ch-8.7.1-infusion-pump.adoc b/asciidoc/volume3/tf3-ch-8.7.1-infusion-pump.adoc index 3b271998..e9ecb5b4 100644 --- a/asciidoc/volume3/tf3-ch-8.7.1-infusion-pump.adoc +++ b/asciidoc/volume3/tf3-ch-8.7.1-infusion-pump.adoc @@ -23,8 +23,8 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Content for this section will be extended in a future version of SDPi. -The initial content will reflect what is provided in SDPi {ihe_supplement_sdpi_revision_short} <>. +a| *{standard_note}*: Content for this section will be extended in a future version of SDPi. +The initial content will reflect what is provided in SDPi {gemini_standard_sdpi_revision_short} <>. |=== diff --git a/asciidoc/volume3/tf3-ch-8.7.2-ventilator.adoc b/asciidoc/volume3/tf3-ch-8.7.2-ventilator.adoc index d42167a2..3ad9b912 100644 --- a/asciidoc/volume3/tf3-ch-8.7.2-ventilator.adoc +++ b/asciidoc/volume3/tf3-ch-8.7.2-ventilator.adoc @@ -20,6 +20,6 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Content for this section will be extended in a future version of SDPi. -The initial content will reflect what is provided in SDPi {ihe_supplement_sdpi_revision_short} <>. +a| *{standard_note}*: Content for this section will be extended in a future version of SDPi. +The initial content will reflect what is provided in SDPi {gemini_standard_sdpi_revision_short} <>. |=== diff --git a/asciidoc/volume3/tf3-ch-8.7.4-surgical.adoc b/asciidoc/volume3/tf3-ch-8.7.4-surgical.adoc index bf18e32f..d7403047 100644 --- a/asciidoc/volume3/tf3-ch-8.7.4-surgical.adoc +++ b/asciidoc/volume3/tf3-ch-8.7.4-surgical.adoc @@ -22,6 +22,6 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: Content for this section will be extended in a future version of SDPi. -The initial content will reflect what is provided in SDPi {ihe_supplement_sdpi_revision_short} <>. +a| *{standard_note}*: Content for this section will be extended in a future version of SDPi. +The initial content will reflect what is provided in SDPi {gemini_standard_sdpi_revision_short} <>. |=== diff --git a/asciidoc/volume3/tf3-ch-c-oid-tables.adoc b/asciidoc/volume3/tf3-ch-c-oid-tables.adoc index 60ab0df1..6820c71b 100644 --- a/asciidoc/volume3/tf3-ch-c-oid-tables.adoc +++ b/asciidoc/volume3/tf3-ch-c-oid-tables.adoc @@ -11,7 +11,7 @@ See https://wiki.ihe.net/index.php/PCD_OID_Management[PCD OID Management]. They have designated `{SDPi-parent-oid}` as the parent OID for a hierarchy of object identifiers for this service-oriented device point-of-care interoperability (SDPi) specification. -This supplement is responsible for the hierarchy underneath the `{SDPi-parent-oid}` SDPi top level oid. +This standard is responsible for the hierarchy underneath the `{SDPi-parent-oid}` SDPi top level oid. Generally, the meaning of OIDs should not change once assigned. For example, `{SDPi-parent-oid}.3.40` will always refer to a RefActor:somds_participant[]. This OID will never be assigned another meaning even if, for some reason, a SOMDS participant is no longer @@ -109,7 +109,7 @@ sdpi_oid_table::[arc="profile-actor-options"] [#vol3_appendix_c_oid_actors] === Actors -The actor definitions in this supplement are assigned OIDs from the `.*3*` arc under under the <>. +The actor definitions in this standard are assigned OIDs from the `.*3*` arc under under the <>. Actor arcs are generally assigned sequentially using the `oid-arcs` attribute on the ASCIIDoc section that defines the actor. sdpi_oid_table::[arc="actors"] @@ -117,7 +117,7 @@ sdpi_oid_table::[arc="actors"] [#vol3_appendix_c_oid_transactions] === Transactions -The transactions defined in this supplement are assigned OIDs from the `.*4*` arc under the <>. +The transactions defined in this standard are assigned OIDs from the `.*4*` arc under the <>. Transaction arcs are automatically assigned when the document is processed by combining the transaction number with the parent OID for transactions. sdpi_oid_table::[arc="transactions"] @@ -125,7 +125,7 @@ sdpi_oid_table::[arc="transactions"] [#vol3_appendix_c_oid_content_modules] === Content modules -Content modules defined in this supplement are assigned OIDs from the `.*8*` arc under the <>. +Content modules defined in this standard are assigned OIDs from the `.*8*` arc under the <>. Content module arcs are generally assigned sequentially using the `oid-arcs` attribute on the ASCIIDoc section that defines the content module. sdpi_oid_table::[arc="content-modules"] @@ -133,7 +133,7 @@ sdpi_oid_table::[arc="content-modules"] [#vol3_appendix_c_oid_use_cases] === Device Point-of-care interoperability use cases -<> defined in this supplement are assigned OIDs from the `.*9*` arc under <>. +<> defined in this standard are assigned OIDs from the `.*9*` arc under <>. * Each use-case feature is sequentially, in the order it is added to the specification, assigned an arc under the `.9` parent OID using the `oid-arcs` attribute on the ASCIIDoc section that defines the feature. This OID identifies the use-case feature and is the parent for its scenarios. * Each scenario in a use-case feature is sequentially, in the order it is added to the specification, assigned an arc under the corresponding feature using the `oid-arcs` attribute on the ASCIIDoc section that defines the scenario. diff --git a/asciidoc/volume3/tf3-ch-z-ics.adoc b/asciidoc/volume3/tf3-ch-z-ics.adoc index ad8720dc..dfb4dfb1 100644 --- a/asciidoc/volume3/tf3-ch-z-ics.adoc +++ b/asciidoc/volume3/tf3-ch-z-ics.adoc @@ -1,10 +1,10 @@ -[appendix#vol3_appendix_d_ics,sdpi_offset=Z] +[appendix#vol3_appendix_z_ics,sdpi_offset=Z] == Implementation conformity statements === General format Implementation conformity statements take the form of tables. Templates for these _ICS tables_ -are given in <>. The tables are completed and provided as an overall conformity +are given in <>. The tables are completed and provided as an overall conformity statement document. Generally an implementation conformity table contains the following information: @@ -28,166 +28,166 @@ The *Support* column may be a simple entry, such as one of the following, or a d * *no*: to requirement is not met, * *n/a*: the requirement is not applicable, with a rationale provided in the *Comment*. -[#vol4_ics_tables] +[#vol3_ics_tables] === Tables ==== SOMDS Participant -RefActor:somds_participant[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_participant[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_participant] +[#vol3_ics_actor_somds_participant] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_participant] ==== SOMDS Provider -RefActor:somds_provider[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_provider[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_provider] +[#vol3_ics_actor_somds_provider] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_provider] ==== SOMDS Consumer -RefActor:somds_consumer[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_consumer[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_consumer] +[#vol3_ics_actor_somds_consumer] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_consumer] ==== SOMDS Connector -RefActor:somds_connector[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_connector[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_connector] +[#vol3_ics_actor_somds_connector] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_connector] ==== SOMDS FHIR Gateway -RefActor:somds_fhir_gateway[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_fhir_gateway[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_fhir_gateway] +[#vol3_ics_actor_somds_fhir_gateway] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_fhir_gateway] ==== SOMDS V2 Gateway -RefActor:somds_v2_gateway[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_v2_gateway[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_v2_gateway] +[#vol3_ics_actor_somds_v2_gateway] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_v2_gateway] ==== SOMDS Sensor Gateway -RefActor:somds_sensor_gateway[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_sensor_gateway[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_sensor_gateway] +[#vol3_ics_actor_somds_sensor_gateway] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_sensor_gateway] ==== SOMDS Smart App -RefActor:somds_smart_app[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_smart_app[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_smart_app] +[#vol3_ics_actor_somds_smart_app] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_smart_app] ==== BICEPS Content Creator -RefActor:biceps_content_creator[] actors indicate conformatity with this profile by completing <>. +RefActor:biceps_content_creator[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_biceps_content_creator] +[#vol3_ics_actor_biceps_content_creator] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=biceps_content_creator] ==== BICEPS Content Consumer -RefActor:biceps_content_consumer[] actors indicate conformatity with this profile by completing <>. +RefActor:biceps_content_consumer[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_biceps_content_consumer] +[#vol3_ics_actor_biceps_content_consumer] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=biceps_content_consumer] ==== Discovery Proxy -RefActor:discovery_proxy[] actors indicate conformatity with this profile by completing <>. +RefActor:discovery_proxy[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_discovery_proxy] +[#vol3_ics_actor_discovery_proxy] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=discovery_proxy] ==== SOMDS Medical Data Provider -RefActor:somds_medical_data_provider[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_medical_data_provider[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_medical_data_provider] +[#vol3_ics_actor_somds_medical_data_provider] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_medical_data_provider] ==== SOMDS Medical Data Consumer -RefActor:somds_medical_data_consumer[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_medical_data_consumer[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_medical_data_consumer] +[#vol3_ics_actor_somds_medical_data_consumer] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_medical_data_consumer] ==== SOMDS Dec Gateway -RefActor:somds_dec_gateway[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_dec_gateway[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_dec_gateway] +[#vol3_ics_actor_somds_dec_gateway] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_dec_gateway] ==== FHIR Medical Data Gateway -RefActor:somds_fhir_medical_data_gateway[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_fhir_medical_data_gateway[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_fhir_medical_data_gateway] +[#vol3_ics_actor_somds_fhir_medical_data_gateway] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_fhir_medical_data_gateway] ==== SOMDS Medical Alert Provider -RefActor:somds_medical_alert_provider[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_medical_alert_provider[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_medical_alert_provider] +[#vol3_ics_actor_somds_medical_alert_provider] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_medical_alert_provider] ==== SOMDS Medical Alert Consumer -RefActor:somds_medical_alert_consumer[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_medical_alert_consumer[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_medical_alert_consumer] +[#vol3_ics_actor_somds_medical_alert_consumer] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_medical_alert_consumer] ==== SOMDS ACM Gateway -RefActor:somds_acm_gateway[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_acm_gateway[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_acm_gateway] +[#vol3_ics_actor_somds_acm_gateway] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_acm_gateway] ==== SOMDS Medical Control Provider -RefActor:somds_medical_control_provider[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_medical_control_provider[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_medical_control_provider] +[#vol3_ics_actor_somds_medical_control_provider] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_medical_control_provider] ==== SOMDS Medical Control Consumer -RefActor:somds_medical_control_consumer[] actors indicate conformatity with this profile by completing <>. +RefActor:somds_medical_control_consumer[] actors indicate conformatity with this profile by completing <>. -[#vol4_ics_actor_somds_medical_control_consumer] +[#vol3_ics_actor_somds_medical_control_consumer] .Implementation conformity statements that apply to all <>s. sdpi_ics_table::[sdpi_req_actor=somds_medical_control_consumer] diff --git a/asciidoc/volume3/tf3-main.adoc b/asciidoc/volume3/tf3-main.adoc index 199b79b7..e2b7693e 100644 --- a/asciidoc/volume3/tf3-main.adoc +++ b/asciidoc/volume3/tf3-main.adoc @@ -13,22 +13,25 @@ [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The organization of this Volume 3 supplement factors in two major changes: +a| *{standard_note}*: The organization of this Volume 3 standard factors in two major changes: + +// STANDALONE TO DO ... this section + . IHE Supplement template (2020), with content mapped from the <> specification; . 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 2024 version that was in sections 3 and 7 has now been collected into a single Section 8. +For this version of the standard, content from the 2024 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. +In order to clearly identify the standard content that is related to <>, specific sections with <> in the title have been added. +Although this results in a fairly clean standard 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 standard 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._* +*_Updating the existing IHE DEV Technical Framework content will be either deferred to a later version of this SDPi standard or will be accomplished through a specific Change Proposal (CP) to the published IHE DEV TF-3._* Additionally, for this version of SDPi, it isn't clear how best to address a similar division of the device specialization sections (e.g., infusion pump or ventilator). Version note boxes (like this one) have therefore been added to the specializations section and a single BICEPS subsection has been added. @@ -45,7 +48,7 @@ Subsequent versions of the specification may address this more comprehensively. [%noheader] [cols="1"] |=== -| Move IHE DEV 2024 TF-3 Section 3 (text immediately after the section header) to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.1 +| Move IHE DEV 2024 TF-3 Section 3 (text immediately after the section header) to this SDPi {gemini_standard_sdpi_revision_short} TF-3 Section 8.1 |=== //// @@ -58,14 +61,14 @@ Subsequent versions of the specification may address this more comprehensively. [%noheader] [cols="1"] |=== -| Move IHE DEV 2024 TF-3 sections 3.1 to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.2 +| Move IHE DEV 2024 TF-3 sections 3.1 to this SDPi {gemini_standard_sdpi_revision_short} TF-3 Section 8.2 |=== [%noheader] [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: The content in the IHE DEV 2024 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| *{standard_note}*: The content in the IHE DEV 2024 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,7 +83,7 @@ a| *{supplement_note}*: The content in the IHE DEV 2024 TF-3 3.1 Section will ne [%noheader] [cols="1"] |=== -| Move IHE DEV 2024 TF-3 sections 3.2 to 3.7 to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.3.1.2 TO 8.3.1..7 +| Move IHE DEV 2024 TF-3 sections 3.2 to 3.7 to this SDPi {gemini_standard_sdpi_revision_short} 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 (2024) Section 3.1, where that content is specific to the Classic DIM (see related note above). @@ -104,8 +107,8 @@ include::tf3-ch-8.3.2.13-metric-display-precision.adoc[] [%autowidth] [cols="1"] |=== -a| *{supplement_note}*: This is a place holder section for content modules related to the Personal Health Device (PHD) semantics defined in the IEEE 11073-10206 and 11073-20601 standards. -Though there are no PHD requirements in this supplement, there are PHD profiles that may be integrated into the IHE DEV Technical Framework, and as a result may add content to this section. +a| *{standard_note}*: This is a place holder section for content modules related to the Personal Health Device (PHD) semantics defined in the IEEE 11073-10206 and 11073-20601 standards. +Though there are no PHD requirements in this standard, there are PHD profiles that may be integrated into the IHE DEV Technical Framework, and as a result may add content to this section. |=== // 8.4 8.5 8.6 RESERVED @@ -114,7 +117,7 @@ Though there are no PHD requirements in this supplement, there are PHD profiles [%noheader] [cols="1"] |=== -| Move IHE DEV 2024 TF-3 Section 4 Reserved to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.4 +| Move IHE DEV 2024 TF-3 Section 4 Reserved to this SDPi {gemini_standard_sdpi_revision_short} TF-3 Section 8.4 |=== === RESERVED @@ -122,7 +125,7 @@ Though there are no PHD requirements in this supplement, there are PHD profiles [%noheader] [cols="1"] |=== -| Move IHE DEV 2024 TF-3 Section 5 Reserved to this SDPi {ihe_supplement_sdpi_revision_short} TF-3 Section 8.5 +| Move IHE DEV 2024 TF-3 Section 5 Reserved to this SDPi {gemini_standard_sdpi_revision_short} TF-3 Section 8.5 |=== === RESERVED @@ -130,7 +133,7 @@ Though there are no PHD requirements in this supplement, there are PHD profiles [%noheader] [cols="1"] |=== -| Move IHE DEV 2024 TF-3 Section 6 Reserved to this {ihe_supplement_sdpi_revision_short} TF-3 Section 8.6 +| Move IHE DEV 2024 TF-3 Section 6 Reserved to this {gemini_standard_sdpi_revision_short} TF-3 Section 8.6 |=== // 8.7