As topics of interest surface during community exchanges, they are recorded in a table, sub-pages created to capture the discussions and resolution, and then updates applied to Gemini MDI+SES artifacts as appropriate.   Note that the table acts as an anchor for each topic, with a confluence page created for each as the discussion begins.  Ultimately, once they are fully discussed, IF they impact other artifacts in SDPi+FHIR (e.g., content in one of the profile specifications), then that is linked in the right column, and a github repo Issue item is created to persist and link the resolution.

What Lays Below ...

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.

NOTENew topics are added to the bottom of the table; it is sorted by priority but can be sorted by other properties as desired.

PriorityTopic DateProposer(s)Lead(s)SynopsisStatusSES+MDI
1-highTopic: Tracing the FDA Design considerations for interoperable systems to 510(k) submission documents2022.02.01Where 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-highTopics:  SES Standards Landscape 2022.02.01Michael 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.   

2-mediumTopic:  Coordination of the FDA ASCA Process to Gemini SES+MDI / CA Process2022.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. 

1-highTopic: SDPi-xC with Mixed Device Safety Classes2020.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

1-highTopic: Issues for Trustworthiness in a "shared risk" decoupled ecosystem2022.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 products2022.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? 

3-lowTopic: 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 & CA2022.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 Nomenclature2021.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-highTopic: Mapping of 11073-10700 bPKP ICS to SDPi2021.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 Products2022.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-lowTopic: SES+MDI Assurance Case for SDC/SDPI+FHIR2022.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 Health2022.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 28002022.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 Standards2022.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


  1. All the content in this table is included on the related Confluence page
  2. "Priority" = 1-high / 2-medium / 3-low / future / <blank> for "new"
    • NOTE1-high = Must be resolved to support next major SES+MDI milestone (e.g., SDPi 1.0 publication & testing)
  3. "Topic" should be a short title that has a hyperlink to the Confluence page where it is discussed
  4. "Date" = when first added to the list
  5. "Proposer(s)" = Those who added and are interested in the topic
  6. "Lead(s)" indicates those individuals who lead the discussion topic to resolution
  7. "Synopsis" = a short teaser for the topic to be explored by the discussion team
  8. "Status" = initiating / prioritized / discussing / waiting (for...) / deferred (to ...) / resolved
  9. "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.



    • 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 Topic Summary & Prioritization

Summary: ... <incl. from ToI table description>

Prioritization:  ... Include topic priority & rationale