Topic Resolution Workflow
This graphic helps with the workflow involved:
Topic Resolution Table
Per the illustration above, this table serves as the central coordination point for all topic discussions and their resolutions.
NOTE: New topics are added to the bottom of the table; it is sorted by priority but can be sorted by other properties as desired.
| Priority | Topic | Date | Proposer(s) | Lead(s) | Synopsis | Status | SES+MDI |
|---|---|---|---|---|---|---|---|
| 1-high | Topic: Tracing the FDA Design considerations for interoperable systems to 510(k) submission documents | 2022.02.01 | Where on the 510(k) ToC the design documentation for interoperable products refer to. Which content can be segregated to review the submission in regard of clinical functionality, supported by the SDC interface. | finalizing | |||
| 1-high | Topics: SES Standards Landscape | 2022.02.01 | Michael Bothe | An important scoping exercise for the Ecosystem Pathway group is identification of those SES standards and guidelines that need to be considered, beyond the technical interoperability specifications as part of the MDI effort. | initiating | ||
| 2-medium | Topic: Coordination of the FDA ASCA Process to Gemini SES+MDI / CA Process | 2022.02.01 | The US FDA has successfully advanced a pilot program "Accredited Standards Conformity Assessment" (ASCA) to establish how formal test reports can be recognized and accepted to meet standards conformance claims within product regulatory submission. | initiating | |||
| 1-high | Topic: SDPi-xC with Mixed Device Safety Classes | 2020.06.23 | What are the rules and guidelines for a SERVICE PROVIDER that supports external control services, and when a SERVICE CONSUMER of a different safety class wants to invoke the control? (see Meeting Logs & Notes - 2020.06.23) (SDPi 1.0) 8/20 Confirmed (need plan for resolution and what / if that is possible) 2022.02.04 Deferred from SDPi+FHIR Topics of Interest table | initiating | |||
| 1-high | Topic: Issues for Trustworthiness in a "shared risk" decoupled ecosystem | 2022.02.01 | An ecosystem of plug-and-trust products that are developed independently (different manufacturers) and "decoupled" (without combinatorial testing during the development process), ultimately SHARE "distributed" risk when implemented and interconnected. What are the issues that the Ecosystem Pathway group needs to consider, including specific risks or risk categories and "system of systems" design constructs (mitigations) that might be employed. | prioritized | |||
| 2-medium | Topic: CA of virtualized vs. physically connected ecosystem component products | 2022.02.01 | Given continued pandemic challenges and the inability to easily convene traditional testing events (e.g., in-person plug-a-thongs and connectathons), how much in-person physically connected component system testing is needed to establish ecosystem confidence vs. virtualized testing which is the persistent reality today? | prioritized | |||
| 3-low | Topic: Considerations for a "Reference System Implementation" | 2022.02.03 | The Gemini CA & Tooling group has been discussing the need for the creation of an "official" ... gold ... Reference System Implementation, that can be used for testing and Conformity Assessment. Question is what roles and requirements the EP community might have for such a system? | prioritized | |||
| Topic: Guidelines for managing process requirements in SDPi specifications & CA | 2022.02.01 | SES standards include requirements that will need to be met, either in part or in whole, but the SDPi+FHIR specifications as well as the implementation & test processes. A consistent set of guidelines for addressing process type requirements will help ensure consistency in the application of all SES standards. | initiating | ||||
| Topic: How are SF/SFC formalized and validated in a PnT Ecosystem? | 2021.11.19 | Core to the SDC/SDPi+FHIR work is the definition of System Functions (SF) and then the System Function Contributions (SFC) that each component product supports when it joins a plug-and-trust (PnT) network. The formalization and specification of these SFs and then the validation at the SF level is a key issue to establishing an ecosystem of products, each of which provide some element of that SF - their SFCs. | initiating | ||||
| Topic: Modeling SES Requirements Test Assertion Methods Nomenclature | 2021.11.19 | When considering requirements from "SES" standards (like, 81001-1, or 11073-1070x) some lend themselves to on-the-wire testing; whereas, others require "document inspection", etc. For the purposes of this Gemini project, we should come up with an agreed set of terms that we use for how to asses testable assertions based on the requirements from these standards. | Initiating | ||||
| 1-high | Topic: Mapping of 11073-10700 bPKP ICS to SDPi | 2021.11.19 | The requirements from the IEEE 11073-10700 base PKP standard are encapsulated in the documents Implementation Conformance Statement (ICS) tables. The SDPi specification (volume 1, appendix B) includes the tables from this specification and maps them to specific SDPi constructs that can then be assessed for conformity. This topic determines those specific mappings or at least the approach that should be taken for establishing the linkages. | prioritized | |||
| Topic: Standards "Chains" Needed for CA PnT Ecosystem Products | 2022.01.17 | In considering "requirements interoperability" - or "standards chains" - which standards chain(s) should we focus on and what does CA for their implementation in an Ecosystem of PnT products require? | initiating | ||||
| Topic: DAS + Smart Alerting Challenges | 2022.02.07 | When considering Distributed Alert Systems and "Smart" alerting, there are challenges that arise around "what can go wrong" (risk management) across various potential configurations of systems. (See related MDI topic: Topic: DAS + Smart Alerting Challenges) | initiating | ||||
| 3-low | Topic: SES+MDI Assurance Case for SDC/SDPI+FHIR | 2022.02.09 | An early but "end game" objective for the Gemini SES+MDI work is to craft a computable & composable assurance case that can be used to organize the argumentation and evidence that would indicate that a component product is indeed SES+MDI. The active ISO/IEC JWG7 project 81001-2-1 assurance case guidance specification may include an example section on this Gemini SDC/SDPi+FHIR work for the claim that it is SES+MDI. How will the ecosystem pathway include a course leading to that end point? | prioritized | |||
| Topic: Formalization of run-time "computable" IFU | 2022.02.09 | As part of a consensus "shared" risk management element of the plug-and-trust product ecosystem, there will be a shared set of instructions for use (IFU) that all system elements will need to implement and expect others to adhere to. These should be "computable", though, discoverable at connection time to the other participating systems, as well as manageable by a supervisory "network health" management system. How should that be achieved? | initiating | ||||
| Topic: Use of MDIRA to Improve PnT Ecosystem Operational Health | 2022.02.16 | The MDIRA Profile (see Specifications: MDIRA / ICE Profile) has been proposed to add capabilities and system component actors that will monitor (in real-time) the operational health of a plug-and-trust network of products. How can the MDIRA components be advanced to truly improve SES+MDI implementations? Which architectural components and which capabilities implemented with which technologies? How much of an impact and improvement on operational safety can application of the MDIRA have? (See also EP home page Reference Materials / MDIRA Materials items) | |||||
| Topic: SES+MDI & UL 2800 | 2022.03.31 | The Gemini SES+MDI specifications (SDC/SDPi+FHIR) should meet the requirements of relevant standards within the AAMI/UL 2800-1:2019 "Safety for Medical Device Interoperability" standard ... yes? And since this standard provides "baseline requirments", how do they relate to the SDC 11073-1070x PKP standards? If at all ... | |||||
| Topic: FDA Recognition of IHE & HL7 Standards | 2022.04.07 | Though the FDA "recognizes" interoperability standards such as the ISO/IEEE 11073 SDC family, it does not currently list any IHE specifications (e.g., IHE DEV ACM profile) or HL7 standards (e.g., FHIR or Version 2). Why? What will it take to recognize specifications such as IHE DEV SDPi-Alerting? (note this is related to the Topic: Alignment of the Gemini SES+MDI / IHE CA Process with FDA ASCA topic). | Discussing |
NOTES:
- All the content in this table is included on the related Confluence page
- "Priority" = 1-high / 2-medium / 3-low / future / <blank> for "new"
- NOTE: 1-high = Must be resolved to support next major SES+MDI milestone (e.g., SDPi 1.0 publication & testing)
- "Topic" should be a short title that has a hyperlink to the Confluence page where it is discussed
- "Date" = when first added to the list
- "Proposer(s)" = Those who added and are interested in the topic
- "Lead(s)" indicates those individuals who lead the discussion topic to resolution
- "Synopsis" = a short teaser for the topic to be explored by the discussion team
- "Status" = initiating / prioritized / discussing / waiting (for...) / deferred (to ...) / resolved
- "SES+MDI" provides a high level indicator of where in the specifications (for example) the topic is addressed once "closed". This may be in sections of the SDPi+FHIR specifications or other documents or artifacts.
Topic Resolution Template
The content below should be added to the head of every new or existing topic subpage.
TOPIC RESOLUTION
<Notes:
- The content in this section of the page will be directly copied to the related sdpi-fhir github repo Issue + integrated into the IHE SDPi Supplement Issues (open / closed) section
- IF the discussion results in numerous independent "issues", modify this TOPIC RESOLUTION section (e.g., multiple instances) to account for each and to be formalized in multiple gethub repo Issue items
- Delete the content between the "<...>"
- Keep the DETAILED TOPIC DISCUSSION content in place & copy-past in this Resolution section as needed
>
Issue Title: <this is what will be used for the github Issue item; it may be the same as the page title or after discussion and resolution, can be modified to something more appropriate>
Issue Status: <indicate if it is still under discussion ("open") or resolved ("closed"); this will determine where it ends up in the SDPi Supplement document Issues section>
Github Issue Link: <add permanent link here for related github issue>
Issue Description
<clear detailed description of the issues related to the general topic; include sufficient detail to provide clear linkage to the Resolution below>
Issue Resolution
<document here the finalize ToI approach, including any technical detail that will need to be integrated into the profile specification document>
DETAILED TOPIC DISCUSSION
dd.mm.yyyy Topic Summary & Prioritization
Summary: ... <incl. from ToI table description>
Prioritization: ... Include topic priority & rationale