Event Info

(Yes - actual picture from the IHE DE Plug-a-thon Event!)

Wherefore Devices? 

 This OR.NET sponsored, held in conjunction with IHE Germany / Devices Domain, is the first official event that builds on the SDC implementer community that has actively participated in ISO/IEEE 11073 SDC standards development, prototyping and demonstration events over the last 10-15 years, and is now beginning to help advance the definition and implementation of the IHE Service-oriented Device Point-of-care Interoperability (SDPi) profiles.  This event provides an excellent opportunity to 

NOTE:  The sections below are intended to capture all event related information, before, during & after.  Subpages can be utilized as appropriate 

Plug-a-thon Preparation

If you have not already ...

#1  Contact Max Rockstroh at OR.NET as soon as possible to get information on joining the event.

#2  Join FREE!  HL7 Confluence - just select the "Request an Account" button.  This will allow you to contribute and better participate in the event content captured on these pages.

#3  IHE SDPi Supplement Introduction 

This plug-a-thon is the 1st IHE event for ISO/IEEE 11073 SDC standards and SDPi (Service-oriented Device Point-of-care Interoperability) profile, and as a result some background on IHE process, technical framework specifications, and testing will be helpful, along with an overview of the profiles being finalized.  Please review the presentation below for this background and introduction information.  

Note:  Feedback on the technical approach to the IHE SDPi profile will be part of the closing Day #2 Takeaways discussion.

#4  PAT Use Case Narrative:  Pandemic Patient in Isolation ICU

It always helps to have a real-world narrative to focus discussions and interoperability challenges.  For this PAT, please consider the following:

Pandemic Patient in Isolation ICU

In dealing with severely infectious patients, healthcare workers (HCWs) are at a significantly greater risk of infection than the overall population due to their frequency and time in contact with the infected patients.  The HCWs will enter the patient room to administer care to the patient and manage the therapeutic equipment. This management of the patient’s therapy may require frequent device adjustments which may be delayed due to the need for the HCWs to protect themselves by donning PPE prior to entering the patient room and doffing the PPE upon leaving.  This donning and doffing processes can exceed 15 minutes depending on the specific PPEs used.  A recent study (Suen, 2018) reported times of 7 minutes for donning and 10 minutes for doffing, with the doffing process providing the opportunity for “considerable” self-contamination.
 
Infectious diseases confer a synergistic burden on and risk to the patient due to the requirements for isolating the patient (Abad et al., 2010) including poorer care and impaired coordination of care, (Mehrotra et al., 2013), significantly fewer HCW and family visits (relative to patients not on precautions) (Morgan et al., 2013), increased rate of adverse events (Stelfox et al., 2003)  and increased depression (compared to other inpatients). (Day et al., 2011).  The use of remote control and monitoring can be used to eliminate some treatment delays, reduce the infection risk to the HCW, and help preserve the limited supplies of PPE and improve patient care.
 
Critically ill patients with an infectious disease will often require monitoring with physiologic monitors and therapeutic support with ventilators and infusion pumps.  As previously explained, entering the room to view parameters or adjust any settings can require 15 minutes for something that may take less than 1 minute.  Medical devices that support open interoperability technology can provide remote access to view parameters and adjust settings thereby increasing efficiency, saving the costs of the PPE and most importantly increasing the safety of the HCW.

(Source: Adapted from AAMI CR Proposal: “Emergency Use Guidance for Remote Control of Medical Devices" ) 

Note that additional information is contained in the introduction slides above.

Consider how your device / system and application might be used in this narrative and what SDC / SDPi capabilities would be of greatest value and use.

Identify other use case scenarios (e.g., for Surgery) that may be of greater immediate interest!

#5  Use Case Prioritization - SDPi Top 10!

Finally, there is a VERY rich set of use cases and scenarios that have informed medical device interoperability (MDI) efforts over the decades, including the ISO/IEEE 11073 SDC standards and now IHE SDPi profiling activities.  Some of these are identified in the 2019 November IHE SDPi paper, and others have been considered as part of the Gemini MDI SDPi+FHIR effort and included in the draft supplement document.  BUT now is the time to finalize what we want in the SDPi supplement 1.0 document, either as top level use cases or at a minimum referenced in Appendix C of the supplement Volume 1.  Kenneth Fuchs created the following spreadsheet with a listing of candidate use cases & scenarios for consideration - you may have your own.  

Please review this spreadsheet - 15 minute scan - and identify the Top 10 (in priority) use cases that you think are most important to integrate into SDPi (1.0).  This will be part of the Day #2 Takeaways discussion.

Plugging away ...

Note this section is to be used DURING the PAT event to capture discussion.

NOTE:  Subpages can be created as appropriate and necessary, but don't overthink it!

Day #1 

Schedule

Discussions / Activities

NOTE:  MS Teams channel will be used for participant exchanges (outside of the audio / video system) - Capture here any information that is particularly useful.

Day #2 

Schedule

• Time	Topic
  09:00-15:00	Work on focus topics, hands-on
  15:00-16:00	Update with Todd on progress and Next steps, Wrap up

Participants

Discussions / Activities

<TBD>

SDPi PAT Takeaways

When the dust settles on the two days of "plugging" and discussing, the following helps inform the journey forward.

Plug-a-thon Summary

<add a general summarization / description of the two days>

Day #2 Debrief Discussion Notes

1. Topic:  SDC => SDPi - Architectural Approach Feedback (profiles / actors / transactions / MDPWS exchanges + content modules)
   1. Transaction Naming:  "topology" vs. "participant" discovery
      1. It was suggested to rename network topology discovery to network participant discovery as the term topology typically refers to the physical network structure like star, mesh, daisy chain topology etc., which is not the level of abstraction that SDC aims at.
   2. MDPWS Message Naming - the message names in the MDPWS Appendix and referenced from the transactions specifications should be made clearer 
      1. The message names in the sequence diagrams laid out here do not match the actual Web Services message names. To facilitate access to the actually exchanged message contents, those should be named in accordance with the respective Web Service specifications. 
   3. Level of detail in TF 
      1. General discussion around how much technical detail that is in the MDPWS & DPWS & WS* standards needs to be duplicated in the SDPi TF
      2. Guideline:  Sufficient technical detail should be included to ensure that SDC-conformance and INTEROPERABILITY are achieved by all adoptors
      3. "Art of Profiling"  was discussed:  too much detail and you are simply reproducing the source standards; too little and you won't achieve either conformity or interoperability!
      4. Example if IHE DEC profile that uses an HL7 V2 "ORU" message ...
         1. The DEC PCD-01 (now DEV-01) transaction references the HL7 V2 standards for basic syntax & ORU static message structure - basic HL7 V2 conformant messaging is assumed in the TF
         2. Only ORU fields that are constrained are then detailed in specific transactions (e.g., fields and message segments that are not allowed because they are out-of-scope for the functionality of the specific transaction in which they are used.
         3. Common message profiling - across all the transactions that use that message - are collected in an appendix in TF-2 for HL7 V2 Message profiling
            1. For example, the use of OBX.3 (???) segment to include a dotted notation for ISO/IEEE 11073 DIM Containment
            2. For example, the use of 11073 nomenclature for specific fields and when appropriate a constrained value set for a field based on 11073 (or other) terminology
   4. Tool testing detail vs. TF 
      
      1. It was noted that SDC test tools test at a much more granular level than SDPi Transactions and profiled MDPWS messages and sequences.  Messages that meet the intent of the TF specifications do not necessarily pass the stricter requirements of the SDC test tooling.  Why?  Is this OK or what should be changed?
      2. Tooling for rigorous SDC conformity testing will be required for Pre-connectathon testing to ensure that all participants bring well behaved systems to the event (this is true of ALL IHE profile testing)
      3. During CAT testing, the primary focus is INTEROPERABILITY, and testing of exchanges will need to be performed - at least on a sample basis - to ensure that the test results are both conformant to the SDC standard as well as the profiled transactions and message exchanges BUT
      4. For CAT test instance documentation, a "pass" or "fail" indication from a test tool execution, together with a time stamp and sending / receiving system identifiers will be sufficient.
      5. In other test tooling (e.g., an IHE Gazelle message proxy tool - man-in-the-middle approach) a link to the test results can be pasted into the Gazelle test instance / test step documentation window OR it can be attached in a file.  
      6. Ultimately, IHE Conformity Assessment (CA) will require very high rigorous testing that utilizes both the pre-CAT conformity testing + the CAT interoperability testing + CA additional details ... 
      7. In other words, testing rigor builds from PAT => Pre-CAT => CAT => CA ... tooling and testing performed at the start should continue and build on to utimate product certification
      8. REMEMBER:  The goal is to enable an ecosystem of interoperable plug-and-trust decoupled products ... and you want to make sure that everyone else plugging into the SOMDS has met the same high bar of CA as your products did!
   5. PKP Now vs. After Published
      1. IF the SDPi Supplement also integrates requirements from the PKP standards and IF those standards will not be fully published until mid 2021 and later, what do we do with SDPi 1.0 now?
      2. The draft SDPi Supplement has "placeholders" for SES requirements for each actor and transaction.  The current version of the supplement will reference the -1070x PKP standards, and subsequent versions of the supplement will integrate detailed requirements when they are finalized.  
2. Topic:  Top 10 MDI for SDPi Use Cases prioritized for use in SDPi Supplement 1.0
   1. Isolation ICU & Silent ICU & FESS (endoscopic surgery) - currently detailed
   2. NOTE: 
      1. Use cases need to be relevant and compelling but not overly complex and beyond the scope of the profile(s)
      2. Not all capabilities indicated by a use case need to be addressed in version 1.0 of the SDPi supplement, but there should be a clear pathway for addressing them in subsequent versions
   3. Proposed inclusion of the UC.130 IHE DEC (from the listing above) for Device to Enterprise communication
      1. This was proposed because of its simplicity and that most of the SDC testing to date has simply been from the device to a SOMDS consumer to an enterprise EHR or similar
      2. This is included in the above use cases, though, so can be mentioned as included and a pathway in SDPi-R enabled BUT it falls short of the "compelling & relevant" objectives stated above
   4. MDIRA Use Case?  
      1. This may be included solely to mention ICE framework in the SDPi 1.0 TF, OR
      2. It may be deferred to the MDIRA Profile (forthcoming) that is built on top of SDPi profiles
3. Topic:  SDPi Profiling Suggestions to facilitate SOMDS performance (at scale!)
   1. Guidance "takeaways" from the PAT for optimizing performance at scale?
      1. Discussion around strategies for optimizing bandwidth consumption / performance
      2. For example, packaging multiple wave streams in a single packet enables increased compression 
      3. Stefan Schlichting Tobias Klotz Will summarize in a "Best Practice" writeup and share with group
   2. Where should this guidance be formalized?  SDPi TF-2 Normative Appendix on MDPWS exchanges?  Elsewhere?
      1. Add as a starting place "Performance Considerations and Guidelines" - Good SOMDS Participant Rules of the Road
4. Topic:  SDC / SDPi Test Tooling (for PAT & CAT & CA)
   1. Actively being discussed in the CA & Tooling group; see discussion above
      1. Key question will be the integration of SDC tooling with IHE Gazelle and related tools + 
      2. Development of test scripts for each of the IHE SDPi capabilities being tested
      3. That will be detailed out in a CA & Tooling Roadmap under discussion and development over the next couple of months
   2. How to achieve using virtualized testing & w/ CAT Monitors etc. 
      1. At in-person events, a Monitor can go to each of the test instance participants and ask them to re-run the test, so the Monitor can review in real-time 
      2. Example was monitoring device parameters reported from System A to System B, the Monitor can observe them on System A, then have them change them and see them displayed on System B. 
      3. How will this work for virtualized for Monitors?  
      4. This will be understood better after the IHE EU CAT in November, and plans for the IHE NA CAT in March are finalized
5. Topic:  SDC / SDPi Plug-a-thon Events - Considerations for next time around?
   1. Preparation?  
      1. VPN worked well! 
      2. MS Teams & Skype meetings worked well
      3. Confluence page was very helpful
   2. Focus / Topics?  Engage Value to Participants?
      1. <... Tobias Klotz ???>
   3. Next events?
      1. One day virtual workshop - November / December?
      2. PAT in December / January / February?
      3. CAT - NA but $8K is serious challenge ... esp. for non-Commercial participants and especially when the value proposition (e.g., market opportunity) is still "emerging"
         1. Note that these costs for the EU and NA CAT are driven by the overhead of providing a virtualized globally implemented testing platform
         2. Question is whether that is needed at this stage for the IHE SDPi community?  And if that is true in 2021 vs. 2022 and beyond when the market is more established   
      4. NOTE:  Can schedule IHE DEV CAT events and run our own if that is sponsored by a deployment committee such as IHE DE or USA or Korea etc.
      5. NOTE:  After this PAT debrief, the topic was brought up in the IHE DEV DPI Program monthly web meeting, and there were similar concerns there as well.

Summary of Action Items / Tasks from the two days ...

• Tobias Klotz Stefan Schlichting Summarize in a "Best Practice" writeup group discussions around performance considerations and "Good SOMDS Participant Rules of the Road"
• Todd CooperEngage IHE T&T and IHE USA leadership around issues specific to the needs of the SDC / SDPi Community; queue up the discussion for 2021 Road mapping in the DPI Program group

Materials for the Archive

Attach or link materials to be persisted from the PAT event, including

1. <Final IHE SDPi Supplement Intro & Overview Slides>
2. ...

NOTE:  These materials will also be captured and publicly available in the IHE sdpi+fhir Github repository under a new "events" folder.