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.  

Topics on the Table

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

PriorityTopic DateLead(s)SynopsisStatusSDPi+FHIR
mediumTopic: FHIR to SDC2020.05.15How 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.15The 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
highTopic: Connect Time Delay Algorithm2020.06.23Random 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.23discussing
highTopic: Handling missed discovery messages2020.06.23David 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.23discussing
highTopic: Info exchanged during unsecured discovery2020.06.23Tobias KlotzDuring 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.23discussing
mediumTopic: PoC network architecture scenarios2020.06.23What 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.23initiating
mediumTopic:  SDPi Actor Descriptions2020.06.24The 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.initiating
lowTopic: Relationship of ITI ATNA and DEV SDPi?2020.06.23IHE 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.23initiating
lowTopic: Use of OAUTH for SDPi Authorization2020.06.23SDC/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.23initiating
highTopic: SystemContext Profiling & Use2020.06.23How 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?
  (see Meeting Logs & Notes - 2020.06.23
mediumTopic: "Session" Context2020.06.23The 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.23initiating
highTopic: SDPi-xC with Mixed Device Safety Classes2020.06.23What 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.23discussing
lowTopic: MDIB Version Update Guidelines2020.06.23SDC 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.23initiating
mediumTopic: Profiling BICEPS Services in SDPi-P2020.06.23Todd 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.23initiating
lowTopic: Efficient MDIB Content Discovery2020.06.23Although 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.23initiating
lowTopic: BICEPS Extension Model Use in SDPi?2020.06.23SDC provides for extensions, especially in BICEPS.  How should these be included and utilized in SDPi? (see Meeting Logs & Notes - 2020.06.23initiating
futureTopic: Strategy for Plug-n-Trust Computable IFU2020.06.23For 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.23initiating
lowTopic: Sensor Proxy Device Actor2020.06.23SDC 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.23initiating
highTopic: Alert Delegation Chains2020.06.23Alert 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.23discussing
mediumTopic: MDIB Update Management with Intermittent Connections2020.06.30For 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 Gherking formalization will help.  Mobile (in hospital) including telemetry.  Intent here is that the connection is normally available but can drop depending on environment conditions.initiating
mediumTopic: PROVIDER Initiated vs. CONSUMER Initiated with Intermittent Connections2020.06.30For 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.initiating
mediumTopic: What is a Central?2020.07.08Moving 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 ...)?discussing


  1. All the content in this table is included on the related Confluence page
  2. "Priority" = low / medium / high / future
  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. "Lead(s)" indicates those individuals who lead the discussion topic to resolution;
  6. "Status" = initiating / discussing / resolved; 
  7. "SDPi+FHIR" provides a high level indicator of where in the specifications (for example) the topic is addressed once "closed".