Technical discussions related to the profiling and application of SDC by SDPi+FHIR are captured on the Confluence Topics of Interest page
GitHub sdpi+fhir respository is being used to persist and manage revisions of the Gemini MDI project artifacts, as well as support issue tracking and a project "Kanban" board. See https://github.com/IHE/sdpi-fhir/
NOTE: S3 storage has been added to the Gemini project space for current-only version of files that are linked from the confluence project pages
IHE SDPi Supplement (first draft expected in Q4 2020 (IHE_Devices_Suppl_SDPi_2020-09-21A.docx referenced))
Todd walked through table of content of the IHE Supplement, currently over 150 pages!
Latest draft of this document is always available on the Github repository linked above
The SES MDI framework and approaches technical report is also reflected in the SDPi Supplement draft document via a summary in TF-1 Appendix A, as well as "SES Requirements" sections for each profile and transaction
Todd Cooper will create the S3 storage for this meeting to include the presented materials …
Noted not an all-inclusive list - learning as team goes, open to use of additional standards
Update on the SDC-based MDIRA Reference Implementation & "gaps" identified
Proposals for "gap" mitigations both within the ISO/IEEE 11073 SDC standards group (incl. IEEE PAR proposals)
(see slides) - Scott talked to the following gaps:
To date, not much available for autonomous medical systems
There is no classification (typology) framework for autonomous medical systems
What's required to communicate to ICE Supervisor
What about SaMD?
Challenge of searching MDIBs
Support for MDIRA telemedicine / remote care using SDC/BICEPS…
Consider using HTTP/2 for remote connectivity vs. SDC's baseline MDPWS, and leveraging the improved technologies associated
External control is core to SDC and SDPi-xC ... MDRIA objectives are to leverage that…
IEEE Standards: Project Authorization Request (relying on formality of standards work and diversity of interest and knowledge)
IEEE PAR Consideration shown (see slide #18)
MDIRA is looked at as an "overarching" architecture (see "Hanging Garden" diagram)
NITRD - Networking and Information Technology Research and Development (NITRD) part of the US NCO National Coordination Office
(Cooper) Asks in the MDIRA update:
Set up a regular IEEE 11073 PoCD WG call to discuss and resolve / establish a strategy to address the identified gaps
Possible submission to the next IEEE NesCom meeting
Ken Fuchs suggested addressing this at the Working Group Level
WG would look at and vote on PARS and that would go to Standards Committee then on to NESCOM
John Rhoads - encourage preparing the PARs and moving them forward
Possible a standing Tuesday time slot and PoCD WG (SDC related topic) (10 AM Eastern, perhaps in alternating weeks)
Suggested First Meeting 9/29 - establish this as a planning meeting as well as other SDC topics and plans
Brief IHE Work Item Profile Proposal (MDIRA Version 2020.09.18 Version b)
See proposal here: 1. Proposed Work Item Overview 2. The Problem 3. Key Use Case 4. Standards and Conditions 5. Discussion
9/25/20 - on Friday morning at 9 AM Eastern - IHE DEV DPI Program team meeting to vote on recommending circulation of the Brief Profile Proposal to the IHE Devices domain for review and approval in their upcoming October plenary meetings.
Tooling & Testing(11:00 AM - 12:30 PM)
NIST Tooling Update
RTMMS (Version 2)
SES MDI Framework & CA/Testing (12:30 - 1:00 PM) (Cooper)
Q: (Malcolm Clarke) - what was used as "authoritative?
2019 mainly takes precedence, terms were flagged if any issues; Malcolm Clarke Malcolm suggested running against the spreadsheet vetted at standards meeting as well - agreed by Michael Faughn Michael Faughn
Paul Schluter reiterated Michael's CSV file has been well validated (Michael can provide the .csv with all, Malcolm indicated he will do another check with what he thought is the 10101 content vs. the .csv provided by Michael, and if needed to do a 10101 amendment… such as 10101B, or later 10101C
Q: (Malcolm asked about maintenance from Prometheus vs. Gov't?
Prometheus make use of several plug-ins as part of the Development Process
Who owns these? Prometheus or Gov't
Prometheus has made all such plug-in open source (so from a practical sense all of the development "stuff" code and documentation on how to use all pieces to generate the "Application Server".
Also noted, each Application Server could be hand coded/edited if ever needed (even if this would cause some
Michael showed the RTMMS V2 System and walked through functionality
Action: toddTodd will reach out to Michael Kirwan (PHD Workgroup) to let group know that particular workgroups are aware4
Paul Schluter mentioned that there are > 1M devices that implement, however if the standard expires it still remains on the book, so a revision is not needed. If it's possible to refresh the date that would be a good way to go. Standard does meet all the safety requirements
Action Item: Malcolm Clarke Malcolm Clarke will do a quick PAR, change cover, and keep the content and refresh the date.
Expires on 31 Dec 2020 : Last update was 2016 (by Jan Wittenber)
No one on call
Ken showed a spreadsheet
Medication Monitor 10472 - Korea - there may be a product tied to this standard
(Todd) Cable connected
Trial Use Par 10316: Dialysis Device?
10103a: Amendment is on-going… 31 December
Work is active and a standard is forthcoming
10101C - Ken showed the PAR
Todd Cooper first, Paul Schluter second
Passed: 20-0-0 (For-Against-Abstain)
Bjorn Anderson - PAR was submitted for terms
Terminology is on SourceForge and will be looked at tomorrow during Q1&
(Stored on DEV S3 File Connector Site under WG Materials)
See Slide 2
Paul has been providing a webinar series on Hemodialysis PCD-DEC based Implementation Guide
Ventilators work on going (with good input from industry experts)
MEM DMC - provisionary codes assigned, several other parameters from GE, Massimo, and others…
Hoping to get
Area in grey will not be included in 10101b
See slide regarding parameters
10101B New Devices… (see slide)
Brian Witkowski (BBraun) has produced with IHE-DEV Pump WG a draft pump containment model
Final review on Monday 9/28 at 10 Eastern
Hemodialysis (see slide)
Paul noted information may be imbedded in message (e.g., in HL7 V3 PCD-01)
Treated as a Boolean value in a PCD-01 (allows Clinical non actionable, but you may want to log)
Ventilator Mode (based on ISO 19223)
Paul provided a few examples of ISO 19223 to IEEE 11073 REFID Conversion for Vendor Modes
Document referenced: "VentModelISO.4c.2020-09-02T14.docx" posted on September 3, 2020 on IHE PCD RTM Google Group
Paul indicated there is hope to use ISO codes and has notified legal
Next Steps for IEEE P11073-10101b
In this case there are less a dozen - so get content in a spreadsheet can simply be cut and pasted…
Overall spreadsheet may not be the best approach for larger sets of data
Paul views the provisional code assignment as a solid draft (even if term later goes away from provisional stage)
Submit first ballot draft of 10101b submitted to the IEEE-SA for Mandatory Editorial Coordination (MEC) during December 2020.
Invitations to form and join the IEEE P11073-10101b Ballot Group will be sent out in January 2021
Start IEEE P11073-10101b ballot review, comment and voting!
Bjorn Anderson asked if possible to get a few terms in, how would one go about that…
IEEE p11073-10103R Implanted Devices Cardiac
Ventilator Mode (ISO 19223 & IEEE 11073 & SNOMED alignment)
In future we will Discuss 11073-10101c PAR request and vote (Paul Schluter)
Anesthesia WG (GAS) - (Martin Hurrell ... DEV WG sync with GAS Co-Chairs)
Martin Hurrell (GAS Co-Chair) provided background and overview of the state of the Anesthesia WG
Integration w/ DEV incl. 3 year plan
1st Iteration of DAM, next iteration discussion
The following note summarizes the Aesthesia WG's current plan for the DAM (V2)
A second iteration of the DAM will include:
between 10 and 20 additional detailed procedural use cases
the specification of a 'clinical note' for each use case (effectively, fragments of the e-record)
appropriate SNOMED CT term-bindings for each clinical note. It may be that we will also need to reference specialized device nomenclature that is part of existing standards and may not all be reflected in SNOMED CT e.g.ISO 19223 (ventilators), ISO/IEEE 11073-10101 (poc device nomenclature)
Next; work - incl possible focus on Gemini SDPi+FHIR component around surgery & anesthesia workstations & SOMDS Gateway to EHR etc.
Further elaborate the use cases
e.g., isolate the lung technique
Define the clinical note (to capture the salient information of the use case)
Provide the example term bindings to clinical notes (from IOTA and SNOMED- CD about 5K terms mapped to SNOMED)
Next then go to a FHIR IG
Recently, with work of Gemini, take a step back and get the wisdom of the Gemini group and fit into that framework.
Martin asked the group for thoughts on this approach…
Todd Cooper mentioned that on Tuesday we talked about how challenging it is to finalize FHIR IGs…
Todd agreed to work through this WG is a good way to go…
Martin hope is to bring good work to the group, but also to leverage the expertise of the group
Todd mentioned (regarding the Vent terminology) bringing the IEEE terms forward - we are at a unique juncture to bring the work done with the AWG, within the context. Martin mentioned there are lot of details yet to be done with regards to Ventilator devices.
Analytics tooling (Data analytics) now has enough "richness" to predict patients and actions needed immediately
What are solutions that are simple, safe, effective, and secure
Proposal in June
Kosta recognized the many folks involved in the regular meetings within specific areas
Malcolm Clarke noted "Chronic Care" issues during Pandemic - how can "we" move this managed care out into the community.. This is a real struggle (particularly in the UK) which is slightly different the cycle shown in the diagram in slide.
Derrell Woelk - noted that at FHIR Connectathon a few weeks ago, there is a track which is focused on the data and process "Care Coordination Track"
Todd asked, with regards SES, how do we know when a device is SES (Safe, Effective, Secure) which is a unique core of what this technical report provides… Is this a key part of this work? Gora indicated this is a focus and that one session (hosted by Axel Wirth) showed the importance of this. Todd stressed we need there are a lot of folks looking at the "sweet spot"
RCC/MH Team meets every Tuesday from 3 - 5 pm each week.
Having subject matter experts providing presentations and input
Next two Tuesdays, special sessions from
Oct 6th - digital health policy (FDA, CMS, and maybe ONC folks)
Active collaborations with medical communities and interoperability - trials and surveillance are key!!
Real World Data based Smart COVID-19 Management
Type your task here, using "@" to assign to a user and "//" to select a due date
Friday, Q1 + Q2
IEEE Disclosures: (Ken Fuchs, John Rhoads)
Call for Potential Essential Patents Holders. Please contact IEEE WG co-chairs with just name and affiliation.
DeviceMetric has "puzzled" people - what that was for or not…
Action item for HL7 DEV WG:
Get the information out for the detail discussions and in particular the DEV WG is to clarify the text that goes with the DeviceMetricResource in the FHIR Spec - This will happen on a future weekly DoF Call;
Also encouraged to join O&O meetings that occur weekly on Mondays at 3 PM (Eastern):
This is a call in a recurring sequence (and occurs every week )
DeviceMetric is an "extension" effectively of the Device resource.
DeviceMetric is not the same as an ObservationDefinition.
The Observation is the actual observation/result of a Device / DeviceMetric, where a DeviceMetric addresses a particular measurement capability of a Device that generates an Observation, such as the state of that capability, calibration, etc.
The DeviceMetric in essence provides further information on certain capabilities that are documented on a Device or DeviceDefinition.
Needs to be clarified in the Boundaries and Relationships of DeviceMetric. Dev WG will progress that.
That also needs to be done in reverse on ObservationDefinition, Device, and DeviceDefinition by OO WG.
Concerns with overlaps.
Merge DeviceDefinition.specialization and .capabilities to cover both and call it .capabilities that capture what the the device could do.
Update DeviceDefinition.property to reflect all possible properties.
Remove Device.specialization and include Device.capability that mirrors DeviceDefinition for what it is actually capable to perform in use.
With Device.type now being 0..* the Device.specialization purpose can be put into Device.type. It seems that
Collapse into Property.
IEEE 11073 SDC
PKP & ModSpec standards (i.e., 11073-107xx) (Dr. David Gregorczyk, Draeger)
Collection of sub models or containment trees used by multiple/diriment kinds of devices
Idea is to put "user interface settings (e.g., language, brightness, volume, etc.)
Collection of these models to be used in DevSpecs or even b devices that do not have/use a devSpec →
Request for PAR change: IEEE P11073-10725
Request change of Title to "Suction and/or Irrigation Pump" (see rational on slide 7), from old "Endoscopic Pump"
Noted "and/or" --> decided to remove "and/or" in Title and add that detail to "Scope" statement.
Motion made by Martin Kasparick to "Change Title and Scope statement of 11073-P10725", second by Bjorn Anderson
Motion passed 22-0-0
Concept of a "Virtual Terminal" described (see slides 8,9)
Alignment with IEC 60601-2-2 noted
Todd noted that the Coupling of these standards with the world of 60601-2 (perhaps for internal manufacturers product development) is a great opportunity (and one of the first time he's seen the "coming together of these two worlds") and suggested this relationship also applies to David G.'s presentation on PKP…
DevSpec: High Frequency Surgical Equipment (MDS-->VMD--> Channels) broad overview of containment tree provided as well as complete tree representation shown (complexity noted).
Martin discussed and expressed questions on how to reflect the nomenclature…
Malcolm mentioned a bit of confusion on if the terminal is "doing" the control
Martin indicated this is NOT the case… The terminal is not a user interface, but becomes the actual device settings.
Malcolm expressed some confusion of what "virtual" means on "virtual terminal"
Matin showed "Active Output Terminal" from standard - and this not only the active (e.g., touch panel or user terminal)
Paul Schluter mentioned they ran into similar problems "human interface"
Needs to be explicit, vs. abstract or virtual - Paul expressed these are real controls
Martin mentioned this on the VMD and not the parameter
Paul suggested "mode" and/or "mode setting"
Martin indicated they have not yet
Paul: if an enumerated value, there would be in a companion column a complete description; it can be helpful
Bjorn that what have defined are terms for metric, as well as for values (where there are value sets)
SDC only allows Context Free codes (Paul mentioned others don't have these restrictions)…
Malcolm mentioned the PHD specs may be a better model to follow (e.g., descriptions used in PHD for settings and whatever)…
Bjorn believes there are no way to come with terms to those not familiar
Bjorn: "virtual terminal is an abstraction of an interface/ device characteristic"
Future needs: RefID and systematic names - what's shown today is from the context/definitions
Martin had questions for WG: (context of IEC 60601-2-2 description conjunction with description)
Perhaps run the capitalization by Tom Thompson, as per defined terms (matching phrase used in bold in glossary). Capitalization generally used for acronyms. Suggested remove capitalization.
Comment made that "note" should be a continuation of the description (or use End notes for example) - from an IEEE publishing perspective…
Martin mentioned they used two kinds of note: e.g., a look into a specific standards… Paul S. suggested an informative Footnote or perhaps Endnotes… There is also a way to normative as well… if needed.
Agreed that most notes shown are informative
One each for MDS, VMD, Channel and generic
When looking at the current -10101, all terms start with "instrument", but in this case the SMEs mentioned "instrument" is not acceptable… is there concerns?
Paul suggested we need to use a MDC discriminator, if the feeling is this work needs a new category, that could be done… but first and foremost the MDC discriminator is a nice property of 11073
Paul mentioned possible to have a base term to have two discriminator… but in practice sticking to one is a good practice, easier, and easier to read for folks… don't worry about saving bit codes…
Is it allowed to do it this way? And if not, is there
Group indicated this approach seems fine, outside the capital letter (notations)
Question on MDC discriminators?
Group would like to introduce new discriminators to distinguish between (e.g., mono- and bi-polar)
Paul mentioned since these are metrics they might go into the SCATA partition, and you can define your own partition in SCATA… especially if it's anticipated to have several thousand terms down the road this is something to think about… (can be done later)…
EndoCam RTM tree - suggested to look at where there are issues and provide to group for future discussions
No burning questions at this point…
Over the next month, the containment trees, nomenclature will be finalized and stay in touch with committee
Over the next year, future drafts
Motion to adjourn HL7 HCD WG and IEEE 11073 PoCD WG September 21-25 Meetings
Motion by Garguilo , second by Bjorn Anderson
Motion approved 18-0-0 (for-against-abstain)
September 2020 Virtual Joint HL7 DEV + IEEE 11073 PoCD WGs Meeting Adjourned by Co-Chairs
DEV WG is to clarify the text that goes with the DeviceMetric John Rhoads
Type your task here, using "@" to assign to a user and "//" to select a due date