Page tree
Skip to end of metadata
Go to start of metadata

As the Gemini SDPi+FHIR community identifies and works through various topics of interest (see Community Engagement) the pages below capture the resulting information and ultimately the resolution / decisions that were made for addressing the subjects in the SDPi+FHIR program.  

Note:  See also Ecosystem Topics of InterestTopics of Interest - MDIRA


Topic Resolution Workflow 

This graphic helps with the workflow involved:  (borrowed from Ecosystem Pathway Topics of Interest page)


   
















Topics on the Table

As topics of interest surface during community exchanges, they should be included in the table below:

PriorityTopic DateProposer(s)Lead(s)SynopsisVersionStatusSES+MDI
2-medTopic: FHIR to SDC2020.05.15
How should information obtained from FHIR-based sources be represented in an SDC/BICEPS description model?  Usage of the WorkflowContext, for example. 
initiating
futureTopic: BICEPS as Next Gen MDI Model2020.05.15
The ISO/IEEE 11073-10201 "DIM" was developed in the late 80's / early 90's and has been used in other ISO/IEEE models including 11073-20601 and 11073-10207 SDC/BICEPS.  Is there a rationale for passing the core MDI standard baton to BICEPS for emerging and next generation med tech systems?
initiating
1-highTopic: Connect Time Delay Algorithm2020.06.23
Random time delay algorithm needed to ensure that all CONSUMER systems do not try to connect with new PROVIDER at instant of "Hello" announcement;  for example, connecting an infusion pump to an SDC network with 1,000 other systems connected (see Meeting Logs & Notes - 2020.06.23)   SDPi 1.0resolvedTF-2
1-highTopic: Handling missed discovery messages2020.06.23
David GregorczykAn agreed approach is needed to handle the potential cases where discovery messages (e;g., "Hello" or probe / implicit & explicit) are missed due to network conditions or PARTICIPANT system status. For example, a simple periodic "retry" algorithm.  (see Meeting Logs & Notes - 2020.06.23)   SDPi 1.0resolvedTF-2
1-highTopic: Info exchanged during unsecured discovery2020.06.23
During initial Network Topology Discovery, which is unsecured, what information can be exchanged (what must NOT be exchanged) to enable the appropriate system-to-system connections? (see Meeting Logs & Notes - 2020.06.23)  SDPi 1.0resolved
2-medTopic: PoC network architecture scenarios2020.06.23
What alternative network architectures should be included for PoC devices.  For example, with or w/o a SOMDS proxy to a multi-bed network.  Use of location context vs. subnet architecture. (see Meeting Logs & Notes - 2020.06.23
initiating
2-medTopic:  SDPi Actor Descriptions2020.06.24

The basic concepts of an SDPi PARTICIPANT and SDPi CONSUMER and SDPi PROXY are easy enough, but what happens when we want to talk about a "cockpit" actor in an OR or ICU bed?  What does a "central" mean in the context of SDC / SDPi-based connectivity?  NOTE:  This is related to the "Topic:  PoC network architecture scenarios" above. 

See "What is a central?" below too.


initiating
3-lowTopic: Relationship of ITI ATNA and DEV SDPi?2020.06.23
IHE ITI ATNA (Audit Trail / Node Authentication) is widely used in HIT environments.  Is there a point of intersection between ATNA and SDPi security?   (see Meeting Logs & Notes - 2020.06.23
initiating
3-lowTopic: Use of OAUTH for SDPi Authorization2020.06.23
SDC/SDPi uses WS-Security for CIA; however, there are some arguments for using OAUTH for authorization (once authentication has been established) vs. using the SDC SystemContext mechanisms (see Meeting Logs & Notes - 2020.06.23)
initiating
1-highTopic: SystemContext Profiling & Use2020.06.23

How should SDPi profile use of the SDC SystemContext (Location, Patient, Ensemble, Workflow) capabilities?  Including device pairing / coupling using which SystemContext component?  Profile vs. PKP standards?  

13.10.22:  For 1.x include use cases to define logical groups of devices in multiple scenarios (OR, central station, emergency room, etc.)
  (see Meeting Logs & Notes - 2020.06.23)  

SDPi 1.0 + 1.xdiscussing
2-medTopic: "Session" Context2020.06.23
The concept of a "session" leveraging EnsembleContext has been proposed.  Would this be useful for closed-loop control (CLC) and similar applications? (see Meeting Logs & Notes - 2020.06.23)  
initiating
2-medTopic: 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.xdeferred (EP discussion)
1-highTopic: MDIB Version Update Guidelines2020.06.23
SDC provides "version" indicators to enable CONSUMER systems to determine what has changed.  However, this can result in considerable "chatter" on the network if not properly managed.  Also how managed with waveforms vs. parameters.   (see Meeting Logs & Notes - 2020.06.23)   See Topic:  Performance Guidelines below for discussion & resolutionSDPi 1.0initiating
1-highTopic: Profiling BICEPS Services in SDPi-P2020.06.23
Todd CooperSDC/BICEPS provides a general service model that supports many implementation approaches.  How should the services be utilized in SDPi-Plug-n-trust 1.0?  (see Meeting Logs & Notes - 2020.06.23)  SDPi 1.0initiating
3-lowTopic: Efficient MDIB Content Discovery2020.06.23
Although SDC provides a number of ways for a CONSUMER system to discover and navigate a SERVICE PROVIDER's MDIB, for simple devices & applications that only want to find and subscribe to a few parameters, the overhead can be significant.  However, processing complexity needs to be balanced between devices (typically resource constraint) vs. consumer systems (see Meeting Logs & Notes - 2020.06.23)  
initiating
1-highTopic: BICEPS Extension Model Use in SDPi?2020.06.23
SDC provides for extensions, especially in BICEPS.  How should these be included and utilized in SDPi? (see Meeting Logs & Notes - 2020.06.23)   SDPi 1.0 / 1.xinitiating
futureTopic: Strategy for Plug-n-Trust Computable IFU2020.06.23
For establishing SES MDI Plug-n-Trust using SDPi-enabled solutions, what information should be included at discovery / connection time and how should it be represented - and trusted!  (see Meeting Logs & Notes - 2020.06.23
initiating
3-lowTopic: Sensor Proxy Device Actor2020.06.23
SDC excludes direct connection of sensors to an SDC network - how can a light-weight SDPI-based "sensor proxy" actor be utilized to make this information available to consumer systems? (see Meeting Logs & Notes - 2020.06.23
initiating
1-highTopic: Alert Delegation Chains2020.06.23
Alert delegation from a source PARTICIPANT to a delegated-to PARTICIPANT is simple enough (e.g., for cockpit scenarios); but what happens when the delegated-to PARTICIPANT adds its own "smart" alarm conditions and then either delegates to a 3rd PARTICIPANT or needs to transition delegation to another system (e.g., from bedside to central)? (see Meeting Logs & Notes - 2020.06.23) Note:   Waiting for 11073-10702 Alert PKP development to progressSDPi 1.x / 2.0waiting
2-medTopic: MDIB Update Management with Intermittent Connections2020.06.30
For example, when you have a Wi-Fi connection on a patient-to-patient (e.g., spot check monitors, infusion pumps, etc.), at reconnection, how to re-establish patient & location contexts, MDIB changes, etc.  NOTE:  these would be alternate scenarios for a use case to establish requirements, then detail technical approach (TF-1 then TF-2); perhaps Gherkin formalization will help.  Mobile (in hospital) including telemetry.  Intent here is that the connection is normally available but can drop depending on environment conditions.  Note:  Consider "History Service" alternative.SDPi 1.x initiating
2-medTopic: PROVIDER Initiated vs. CONSUMER Initiated with Intermittent Connections2020.06.30
For wearables esp. with battery constraints, devices are only connected intermittently and initiate "upload" when re-connected.  NOTE:  11073 Classic (Manager initiated), 11073 PHD (Agent initiated); SDC/SDPi - how to manage both?  NOTE:  Use case scenarios should capture these.  this is normal operation for these devices.  Note: strategy could be to establish eventing with a CONSUMER and then at a established periodicity to publish updates and go quiet again etc.)  
initiating
1-highTopic: What is a Central?2020.07.08
Moving from the OR to ICU SDPi-based interoperability, there are new systems that come into play, including a "Central Station".  But what is the essence of a "central"?  How should we model and profile that?  And how does this relate to other abstract "actor" specifications get captured and at what level (Narratives ... architectures .. specializations ...)?  SDPi 1.0resolvedTF-1, TF-3
3-lowTopic:  Provisioning PnT RCMs During Implementation Phase2020.07.17
The 81001-1 temple model integrates a life cycle model that we have used to indicate an "SES MDI Trust Gap" region that exists between an SDC/SDPi-enabled DECOUPLED product being put on the market and its implementation (deployment) in an end-user networked I.T. environment.  Problem is that many SES (e.g., risks) cannot be fully understood until risk management (e.g., 80001-1 2nd edition) has been performed in that environment.  The SDC/SDPi SFC can be specified but there will have to be place holders for Risk Control Measures (RCM's) that are determined at deployment, but how and when and "if" this will be provisioned into Plug-and-Trust decoupled products? 
discussing
1-highTopic:  MDIB/MDS Modeling for Device Aggregators2020.07.22
Although SDC allows for an MDIB to have multiple MDS containment trees (all at a single level - not "nested") this results in potentially significant complexity (e.g., maintaining unique handles across an MDIB with multiple MDS's).  A common reason for having multiple MDS's is when you have a device "aggregator" or gateway or similar system.  How should this be modeled using SDPi BICEPS profiling?  SDPi 1.1discussingTF-1, TF-3
3-lowTopic:  SFC + Computable IFU in MDIB/SystemContext2020.07.23
Computable Instructions for Use (IFU) and System Function Contribution (SFC) specifications are key to achieving plug-and-TRUST connectivity.  But how are they specified, integrated into a device's MDIB, especially SystemContext descriptions, and how is CA and discovery at PnT addressed.  (Related to Topic: SystemContext Profiling & Use)  
discussing
1-highTopic:  Security Certificate Provisioning2020.10.02
ISO/IEEE 11073-20702 MDPWS defines how WS-Security w/ X.509 certificates and Extended Key Use (EKU) provisions should be adapted for SDC; however, SDPi profiles will add specificity + address operationalization challenges (globally!).  SDPi 1.0 + 1.xdiscussing
1-highTopic:  Discovery Proxy Actors2020.10.02
David GregorczykISO/IEEE 11073 SDC provides for both implicit and explicit discovery; however, for some implementations this may result in unwanted message traffic across the network; the use of a "discovery proxy" has been proposed and may be added as an optional SDPi actor.  SDPi 1.1discussing
3-lowTopic:  SDC in the Cloud2020.10.09
Considerations for how SDC / SDPi-based connectivity may be achieved using cloud-based infrastructure. ADD HTTP/2 gRPC link to Discovery Proxy & web-friendly certificate management / provisioning etc.   See also  gRPC/protobuf topic
discussing
3-lowTopic:  Remote Maintenance2020.10.09
This general topic impacts SDC/SDPi connected systems, but how specifically should it be supported.  Relationships to other standards and profiles (e.g., MEM/DMC) or company specific extensions, etc. 
discussing
2-medTopic:  Performance Guidelines2020.10.23
Implementations of WS-* based SDC / MDPWS may be extremely resource "hungry" adversely impacting overall SOMDS performance, especially at scale (e.g., 1000 participants on a single SOMDS).  SDPi should establish "Rules of the SDC Road" performance guidelines and expected performance levels for all participating systems. (See related Topic:  SDC for Remote & Cloud-based Connections and gRPC potential option)  ... at least a starter list of do's / don'ts!SDPi 1.xinitiating
1-highTopic: SDPi-P Compression Option2020.11.09
SDC / MDPWS provides for compact representation; however, implementation of that capability technical approach in the industry is very minimal.  The feature is needed though, especially to reduce overall network traffic.  What are the alternatives that might be profiled in the SDPi-P profile under this option?  Note that this is also related to Topic:  Performance Guidelines.  Note:  gzip/deflate now, couple with gRPC for more laterSDPi 1.0discussing
2-medTopic:  Precision Time Protocol Option2021.02.23

Given potential latency issues that are of key concern in some applications, such as alerting where there are hard end-to-end communication real-time requirements, a higher precision time synchronization may be a good option.  NTP is the default time synchronization protocol for SDC; however, the IEEE 1588-2019 Precision Time Protocol (PTP), though too "new" to be widely implemented, is recognized as a good alternative.  Note:  Depends  on the maturity of the protocol.


discussing
futureTopic:  Time-Sensitive Networking2021-05-05
IEEE 802.1 has a group focused on developing standards around Time-Sensitive Networking. What is the relationship and relevance to SDC/SDPi-based connectivity?  How will haptics be managed (e.g., a joystick used during surgery either for video camera or robotic-based surgery)? Closed-loop control between ensemble participants?    Hard real-time SDC, anyone?!
discussing
futureTopic:  Profiling User Interfaces2021-05-05
In the SDC "research" community (e.g., PoCSpec modspecs work and elsewhere) there has been discussion about if and how to specify "user interfaces" when there are risks that must be managed in real time network operation (e.g., not allowing a given safety critical display item to be hidden under a window, OR key common look-and-feel requirements).  A language for this could be crafted easily enough to communicate the requirements in real-time operation of a "decoupled" heterogeneous ecosystem of products; however, this area has historically been "off limits" and identified as crucial to product differentiation.  Assuming that there is a middle ground to be achieved, how might that work in an SDC/SDPi+FHIR world?
discussing
2-medTopic:  LLDP Support2021-05-25
Martin KasparickLink Layer Discovery Protocol (LLDP) is an investigatory topic emerging from the PoCSpec project to address a number of "localization" issues.  What is the potential relationship of this to an SDPi-P Option? Note:  cybersecurity must be managed carefully; not required for SDC but a value add 
initiating
1-highTopic:  DAS + Smart Alerting Challenges2021-05-20

In working through the in-the-weeds details for the SDPi DAS & Smart Alerting System use cases, a number of issues surfaced that should be evaluated and solution direction crafted.  What are the core issues and when do they need to be addressed in the specifications?  What requires updating to the ISO/IEEE 11073 SDC core standards vs. can be profiled in SDPi?  Note:  Dependency on Alert PKP

SDPi 2.0discussing
2-medTopic:  SFC OID Management2021-08-12
Some OIDs (e.g., for System Function Contribution specification) are defined in the ISO/IEEE 11073 SDC standards, others in the SDPi supplement, and then there will be additional vendor & deployment specific OIDs ... where will these be formally defined, maintained, accessed?  (see related Topic:  Security Certificate Provisioning)  SDPi 2.0initiating
2-medTopic:  Patient Info vs. ADT from PoC2021-08-21
SDC defines a PatientContext and a WorkflowContext.  When looking, for example, at potential FHIR-based exchanges through a "FHIR Gateway" actor, it has to be clear when there is a simple accessing of information (e.g., using IHE PIXm or PDQm) and when there is ADT workflow automation at the point-of-care being targeted.  What is the dividing line for the capabilities intended in the SDPi profiles and currently defined actors?  (see related Topic: SystemContext Profiling & Use SDPi 1.xdiscussing

2-med

Topic:  Nested MDS Support2021-10-22
The "classic" IEEE 11073-10201 Domain Information Model (DIM) supported the concept of nested MDS objects (i.e., an MDS can contain other MDS objects, limited to some practical depth containment tree depth level), but that isn't supported by SDC/BICEPS.  Some systems work much better with this support though!  (Note:  This is a residual from the resolution of Topic:  MDIB/MDS Modeling for Device Aggregators ). 
initiating
2-medTopic: Context state retrieval2021-11-22
David GregorczykThere is no requirment that asks for including context states in secured GetMdib/GetMdState response messages, which is highly recommendable to simplify requesting the whole MDIB.
initiating
2-medContainment Tree traversal2021-11-22
David GregorczykThe containment tree service is a utility that comes into play when aiming at gradually/partially requesting MDIB content. Unluckily, the latest version of BICEPS (2017) did not specify the containment tree behavior appropriately.
initiating
2-medTopic:  gRPC / protobuf Transport Option2021-12-17

One option to address inherent performance and complexity issues using MDPWS infrastructure is to replace it with an alternative:  gRPC / protobuf.  Early prototyping has shown that this is not only feasible but should be seriously considered - sooner than later!  Though this approach has been woven in other Topics of Interest such as Topic:  SDC for Remote & Cloud-based Connections, it is time to look at it directly and determine whether it should be implemented, and if so - how!  


discussing
2-medTopic: Try-and-error procedure to find out supported operations when WSDL is not available2021-12-20

The WSDL service in optional in the context of SDC. Consumer needs a guideline how to retrieve the meta information in the absence of the WSDL.


discussing
2-medTopic: Request/response timing when SDC provider is unable to handle request2021-12-20

SDC CONSUMER may send the next request after the PROVIDER responded to the previous request. However, the SDC PROVIDER may not be able to deal with the next request and needs the SDC CONSUMER  to wait. How should the PROVIDER announce this?


discussing
1-highTopic: What is a Smart Alert System?2022-03-10Though the concept of a "smart alarm system" (or subsystem) is often mentioned in various discussions (like Topic: What is a Central? above), it is never clearly defined or described. SDPi 1.0resolved
1-highTopic: Alert Delegation Efficiency2022-03-10Though alert delegation is a core capability of the 11073 SDC standards, the approach has an individual alert condition focus and does not scale efficiently with devices that have multiple simultaneous conditions being annunciated.   SDPi 2.0discussing
2-medTopic: System Types Nomenclature2022-04-04As identified in Topic: Info exchanged during unsecured discovery, new nomenclature needs to be defined for system types, including Central, SAS, Gateway, Aggregator, ...SDPi 1.0discussing
1-highTopic:  SDPi BICEPS Extension Namespace2022-04-04

Given the technical approach to Topic: Info exchanged during unsecured discovery, namely to define an extension to BICEPS and then a urn that can be exchanged during discovery time, a general approach for a formal / long term sdpi-biceps-extension URL namespace should be defined.

SDPi 1.0resolved
2-medTopic:  DIS/DAS/SAS Design Guidelines  2022-04-08

In working through all the "corner cases" - what can go wrong - with the Topic:  DAS + Smart Alerting Challenges, numerous configurations were identified as "Well, OK, you could do that but in the real world ... no one really does", or worse!  Proposal was to collect the wisdom gleaned from those discussions in to a technical paper to capture design guidelines for the creation of DAS / DIS / SAS system components utilizing SDC/SDPi+FHIR specifications. (Prioritize after core Silent ICU topics)


discussing
2-medTopic:  SDPi for Infusion Pump Aggregators2022.04.14

Though infusion pump specialization modeling in SDC is well understood (see model created by Stefan Schlichting ), how exactly will SDC/SDPi profile pump "channels" that can be dynamically added/removed from a docking station?

SDPi 1.x?discussing
2-medTopic:  Proxy Service Architectural Approach2022.04.19Though the "proxy" subject is linked to a few other topics in this table, all of which are marked as medium or low priority, there is no specific discussion around the general, architectural approach to gateway / proxy service actors, and the existing SDC standards do not add much beyond defining the term.
discussing
1-highTopic: MDIB Report Retrofit / Best Practices2022.05.20MDIB reports are sent out every time descriptors or states of an MDIB containment tree change, but BICEPS lacks requirements when it comes to the generation of report messages to the extent that BICEPS Service Consumers cannot appropriately be implemented at reasonable costs.  What to do?  See related Topic: MDIB Version Update Guidelines above.SDPi 1.0discussing


2-medTopic: Unique Identification of SaMD Instances2022.09.16Peter Kranich Bjoern Andersen 

The UDI of software-only devices does not have to be unique per instance but per version. For deployments in which it is necessary to identify multiple instances of the same software, the SYSTEM OWNER and/or ADMINISTRATOR must be assigned the responsibility to deal with this issue.

The Glue revision shall include a requirement for the MANUFACTURER to delegate this responsibility wherever appropriate (see also SDC / 11073-20701 Amendments, Corrigenda & Errata / #64 unique identification of SaMD instances (sourceforge.net)). However, if a solution is required in a shorter timeframe, the solution should be described in SDPi as an interim step and later moved to the Glue standard.


discussing
2-medTopic: Localization Service option2020.11.18The current BICEPS LocalizationService does not address country-specific encodings of dates or numbers, among other issues. which needs to be supported in SDPi + extended to a revision of BICEPS.SDPi 1.xdiscussing

Topic:  Archival Service / Backfilling Support2022.10.13The current BICEPS Archival Service is not a workable solution.  A number of alternative approaches have been suggested.  Note this supports backfilling as well (See also Topic: MDIB Update Management with Intermittent Connections above).  Which should be supported in SDPi?SDPi x.xinitiating

NOTES: 

  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.


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