Skip to end of metadata
Go to start of metadata

Date: September 21 thru 25, 2020

Quarters: Q1 Tuesday - Q2 Friday

Note: Meeting Note Content updated for all sessions through Friday, September 25th for September Meeting; pending review and approval.

Prior Meeting Minutes

These minutes reviewed and approved by on an announced Conference Call of the Health Care Devices (DEV) WG on 2020-02-26

X
  • Note: May 2020 Working Group Meetings Cancelled, therefore no meeting minutes to review/approve.

Goals

Set goals, objectives or some context for this meeting.

Discussion items

TimeItemWhoNotes

 
Monday, Q1 & Q2

Plenary in morning, no HL7 DEV or IEEE PoCD meetings

Officers:

IEEE 11073 SC Leadership:

CHAIR: KEN FUCHS    

SECRETARY: JOHN RHOADS

IEEE-SA Liaison: Tom Thompson

IEEE 11073 PoCD WG Leadership:

CHAIR: JOHN RHOADS  

SECRETARY: JOHN GARGUILO

HL7 DEV WG Leadership:

CO-CHAIR:  TODD COOPER   

CO-CHAIR: CHRIS COURVILLE

CO-CHAIR: JOHN GARGUILO

CO-CHAIR: JOHN RHOADS   

(Scribe: John Garguilo, please review, edit, and update as needed)

No IEEE 11073 PoCD or HL7 Devices WG meetings Scheduled

General Session Speakers:

  • Walter Suarez, MD, MPH, FHIMSS
    • Chair, HL7 International Board of Directors
    • Executive Director, Health IT Strategy & Policy, Kaiser Permanente - Information Technology
  • Bernardo Mariano
    CIO, World Health Organization
  • Renato Sabbatini, PhD, FIAHSI
    CEO, Edumet Institute
    Education Co-Chair, HL7 Brazil
  • Amy Abernethy, MD, PhD
    Principal Deputy Commissioner & Acting CIO, US Food & Drug Administration
  • Ken Goodman, PhD
    Professor, Director, Institute for Bioethics & Health Policy
    Co-Director, University Ethics Programs, University of Miami Miller School of Medicine

No Action Items for Monday Q1 & Q2

  • Type your task here, using "@" to assign to a user and "//" to select a due date

 
Tuesday, Q1

  • Welcome, Introductions, and Agenda Review (Garguilo, Co-Chairs)
  • IEEE Disclosures: (Ken Fuchs)
    • Call for Potential Essential Patents Holders. Please contact IEEE WG co-chairs with just name and affiliation. 
    • Review of IEEE-SA Copyright Policy - IEEE Copyright Policy
  • HL7 DEV / Updates & Biz (John Rhoads + Co-Chairs)
  •  
  • Type your task here, using "@" to assign to a user and "//" to select a due date

John Garguilo (and Co-Chairs


Ken Fuchs and John Rhoads




John Rhoads

(Scribe: John Garguilo, please review, edit, and update as needed)

Welcome, Introductions, Rules

  • Welcome by  John Garguilo (HL7 Co-Chair and IEEE PoCD Secretary) and Co-Chairs
  • Garguilo provided Introduction to meeting, ground rules, & Introduction by attendees (all Virtual / on-line)
  • Ken Fuchs (IEEE-SA 11073 Chair) provided IEEE Patent and Copyright Policies 
    • No patent issues mentioned by attendees on Teleconference
  • John Rhoads provided HL7 Policies
    • No questions or issues regarding HL7 WG raised by Virtual attendees
  • Agenda review (Garguilo) - Mixed content for HL7 & IEEE sessions (Tuesday through Friday, 21-25 September 2020
    • No Action items Q1 ...
    • Type your task here, using "@" to assign to a user and "//" to select a due date

 
Tuesday, Q2

  • HL7 DoF - focus 
    • PSS review / advancement etc. 
    • IG publication completion 

Todd Cooper /

Chris Courville

Devices on FHIR Implementation Guides

  1.   Point-of-Care Devices (PoCD) Implementation Guide
  2. Personal Health Device (PHD) Implementation Guide

From <https://confluence.hl7.org/display/DOF/Devices+On+FHIR>

  • Triage the IG Issues List (from what John Rhoads migrated from JIRA to Confluence via his program)
  • PHD and PoCD version have been balloted
  • PHD IG Publication
    • Ready to be published…
    • Last update was a form was completed (however there appears to a "new" form which Martin Rosner is looking into…)
  • New material has been made available (e.g., Stefan Karl for PoCD, and Catherine for PHD)
  • Need to determine what issues have to be addressed to go to another ballot… (which is a longer term time line)
  • Next Step: future meeting to address HL7 IG requirements…
  • Other Projects or Devices on FHIR updates?
    • Chris Courville Chris Courville will continue on Device Reporting information needed by HL7


 
Tuesday, Q3

  • 11073 SC
    • P&Ps
    • Elections
  • 11073 PHD focus 
    • PARs and Projects
    • Generic Measurements
    • Direct-to-Cloud
    • 11073-10206
    • NOTE:  Can distribute slides w/ projects status and simply ask if there are any questions vs. talking through and discussing 

Ken Fuchs / John Rhoads


Michael Kirwin 

(Scribe: John Garguilo, please review, edit, and update as needed)

11073 SC (Ken Fuchs)

  1. P&Ps
    1. Ken noted that common P&Ps were developed for the 11073 WG
  • Word "Sponsors" to "Standards Committee" were changed throughout…
  • Waiting for NESCOM
    • IEEE is having a virtual F2F this week (?) so likely to be days on approval from IEEE
  • Status of PARs and Projects (Asked about by Malcolm Clarke)
  • Ken extracted a spreadsheet of all the standards (See "ParsStandardReport.xls)
  • Standard Expiration Date on several
    • Although several have expired dates, they have PARs, or are revised
      • E.g., PAR for -10442
    • Malcolm walked through the ones with expired dates, recommended sending an email to Michael Kirwan with the current intentions
  1. Elections (WG PoCD and PHD Chair and Secretary)
    1. No elections held within the past few years
    2. Next - think about elections within the WGs (both PoCD and PHD)


11073 PHD focus (Michael Kirwin, Co-Chairs)

  1. PARs and Projects
    1. Michael Kirwan - was asked of the intentions of the expired standards, and Michael indicated he would bring the list to the WG
    2. Michael presented a slide set
      1. 11073-10206 (lighter weight Domain information model)
      2. Generic Health Sensor
    • Active Work:
      • Brian Rinehart mention standard is a used as a transport, implementation details are not included in std.
      • Cybersecurity
    • New Specialization: Spirometry
  2. Generic Measurements
  3. Direct-to-Cloud
    1. What's the current technical approach
      1. Is currently in 2019 Continua Guidelines…
      2. IoT Direct to Cloud architecture that allows cellular connectivity for devices (like cuff)
      3. Protocol hasn't been established (Brian R. mentioned no m
      4. Discussions are continuing in PCHA, Brian mentioned -10206 can be used (agnostically)
  4. 11073-10206
  5. Martin Rosner mentioned Cyber-security as being part of the Gemini Technical Report
  6. NOTE:  Can distribute slides w/ projects status and simply ask if there are any questions vs. talking through and discussing

Action Items for Q3:

Type your task here, using "@" to assign to a user and "//" to select a due date

 
Wednesday Q1

  • Gemini MDI - SDC/SDPi+FHIR (Cooper)
    • Update on the Gemini Medical Device Interoperability using SDC / SDPi+FHIR program
    • Focus on SES MDI framework and approaches being considered
    • Review IHE SDPi Supplement Draft and Roadmap
  • JHU / APL MDIRA Project Update (Cooper, JHU Team)
    • MDI Project update since last report out September 2019 & (written update) February 2020
    • 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)
    • Discussion of current and future plans for an IHE SDPi-based MDIRA Profile specification

Todd Cooper






Scott Gearhart 

(Scribe: John Garguilo, please review, edit, and update as needed)

Gemini MDI - SDC/SDPi+FHIR (Todd Cooper)

  • Todd provided a "quick tour" on the "Hanging Gardens" project framework 
  • The Gemini MDI joint project between HL7 and IHE has its home groups in IHE Devices / DPI Program & HL7 Devices WG
  • Malcolm Clarke had a question about scoping and relationship with the PHD (Personal Health Domain) which Todd addressed
    • Current focus of SDC & SDPi+FHIR are on the highest acuity care contexts - operating room, ICU, emergency, etc. - and not on healthcare enterprise or home & mobile contexts
    • The PDP and "Loopers" narratives (see below) include aspects of care settings outside hospital-based high-acuity contexts; however, they are included for anticipated future work.
    • Note that there have been (and still are) requests for IEEE 11073 PHD use cases that could be included in the related Compendium of Use Cases that drive the requirements for the Gemini MDI program.

The Gemini program proposal identified a starter set of use case narratives that together span the use contexts comprised by SDPi & FHIR, including (per the project's home page):

  1. Functional Endoscopic Sinus Surgeryu (FESS)
  2. Quiet Hospital / Silent Point-of-Care
  3. JHU/APL MDIRA/ICE for Military & Disaster Casualty Care
  4. Preeclampsia During Pregnancy (PDP) - Care Coordination from Home to Clinic to Hospital
  5. "Loopers" Type 1 Diabetes - Person-crafted Closed-Loop Control

Note:  The above narratives encompass a set of component use cases that ultimately drive requirements specification and ultimately conformity assessment testing of interoperable systems.  

From Gemini MDI Project Confluence home page:

  • 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 …


JHU / APL MDIRA Project Update (Scott Gearhart)

  • Scott provided the JHU/APL MDIRA Project update 
  • See MDIRA update slide set provided;
  • MDI Project update since last report out September 2019 & (written update) February 2020
  • Discussion of current and future plans for IEEE 11073 SDC related standards updates including new PARs, as well as an IHE SDPi-based MDIRA Profile specification
  • As detailed in the slides:
    • Motivated by Army medical critical care in the field (and sustained in the order of days)
      • Autonomous medical Care System - building a technical framework (including the standards to draw upon such that the systems have the characteristics community needs
      • Collaborative project - continue to seek collaborations
      • Goal: "getting feet wet" and building some actual code…
      • Website:  https://secwww.jhuapl.edu/mdira/
      • In the process of developing two MDIRA reference implantations
        • One based on
          • One DDS based (due to complete next year, just started in June 2020)
            • ANSI/AAMI 2700-1, Medical Devices and Medical Systems - ICE (Integrated Clinical Environment)
      • Slide shown on a first MDIRA reference implementation demonstration system layout…
  • MDIRA team's hope to build on base of standards developed over the past several decades
    • IEEE 11073-10101, -SDC, IHE-Devices Technical Framework, AAMI 2700 Part 2-1, HL7 FHIR
      • 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
  • Q&A:
  • (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.



Wednesday Q2

  • Tooling & Testing (11:00 AM - 12:30 PM)
  • NIST Tooling Update
  • RTMMS (Version 2)
  • Tool Process
  • Profile Editor

Garguilo / Michael Faughn



Cooper

(Scribe: John Garguilo, please review, edit, and update as needed)

Tooling & Testing 

NIST Tooling Update (Garguilo / Faughn)

  • John Garguilo introduced session and Michael Faughn presented slide set
  • See Slides
  • Michael walked through the typical development process
  • NIST tooling framework for Device Profiling & Validation (Proposed) presented
    • Includes current and future (known) work…

RTMMS (v2) - Rosetta

      • Terminology Reference Application
      • Enables publications of Terminology Value Sets (e.g., FHIR Terminology Service)
      • Profiling tool will be tightly couples with RTMMS (v2)
      • RTMMS will drive the process from terminology standpoint

Progress since last WGM

    • Finished migration / merge of RTMMS v1 and 10101-2019 into RTMMSV2
      • Analysis and sanity checks
      • Output Terminology in <XML|JSON|CSV> for 3rd party review, post to IEEE, distribute to interested parties
    • Rosetta Containment Profile Tool
    • RTMMS V2… Why?
      • Tie to 11073-10201 for both functionality, understanding, and consistency
      • Needed additional integration and requested user functionality
      • Based on model which makes it much easier to reason about nomenclature elements
      • Easier to maintain from Michael's development work/side…

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
    • Enhanced search capability shown/available (over RTMMS V1)
    • A "Term" is always associated with a RefID and TermCode
  • What's next:
    • Upload a list Terms
      • By .csv, xml, flat file, etc…
      • Valuable for uploading codes from various groups - to validate no "clobbering" of existing codes/ids
    • More explicit exposure of synonyms
    • Source / Event Pairs
    • Others?  NIST/Michael is open to other suggestions from community…
      • Malcolm - could system produce a list of #Defines?
        • MF: It doesn't presently, but could (similar to Annex B)
      • SDO (access controlled view) access and functionality

    • Device Profiles, and in particular Rosetta Containment Profiles
      • From the IHE-DEV "Pump" WG
      • 11073-10201 idea of 'Metric' is too opinionated to sufficiently do this…
      • Maybe we should think about the use of the term 'Metric' in Rosetta Containment Profiles
      • Michael Faughn Should we create a new name for "metrics" which do not measure anything but are really attributes of the MDS (for example)?  Discussion for RTM Call
        • This would be a "…Term" (MDS, no VMD, nor Channel) and about the MDS TermCode/RefID
      • MDS, VMD, Channel, Metric, Facet etc
      • RTM-containment (based on IHE-DEV (formally PCD) Volume 3)
    • Versioning discussed
      • E.g., if you produce a profile which is a child of another profile, and the parents profile changes, does the child's version need to change as well?
      • Complicated - and needs additional consideration
    • Michael has been looking at using "Git" for storing objects and artifacts that become the "source of truth"
    • Making Profile Tools
      • Framework for making a profile tool out of anything for which you have a model
      • 11073-10201 Profile Tool is next…
        • Each tool will likely require some special features
        • The UI is challenging
    • RTMMS v2 Roadmap
      • See slide near end of presentation.
      •  


  • SES MDI Framework & CA/Testing  (Cooper)
    • 12:30 - 1:00 PM…
    • SDPi Update to Volume 3 which would include Biceps profiles from earlier versions and some new ones.
    • Hope is to leverage the work Michael Faughn/NIST has done for both semantics and test tools for SDPi and how to accelerate this test are
    • Part of the "Hanging Gardens" SDPi participant systems to be tested at the interface (and what tooling and how would that work - e.g., testing rigorously the standards and the device specializations)
    • Much more discussion to come on this area…


  • Action Item: @name item..

1 Action Item Assigned

Type your task here, using "@" to assign to a user and "//" to select a due date


Thursday, Q1

  • IEEE Disclosures: (Ken Fuchs)
    • Call for Potential Essential Patents Holders. Please contact IEEE WG co-chairs with just name and affiliation. 
    • Review of IEEE-SA Copyright Policy - IEEE Copyright Policy
  • Review of open Projects and PARs (Ken Fuchs / Tom Thompson)
  • Terminology / Nomenclature (Paul Schluter)
    • 10101 Update 
    • Ventilator Mode (ISO 19223 & IEEE 11073 & SNOMED alignment)
    • LOINC Update (Swapna/NLM & Regenstrief)
  • Discuss 11073-10101c PAR request and vote (Paul Schluter)
  • Anesthesia -  (Martin Hurrell ... sync with GAS Co-Chairs) - Rhoads to coordinate
  • (In parallel @ 10 AM Eastern) JOINT OO  - Courville to Coordinate (incl. meeting times)
    • Hosted by OO (see Whova app for access to WGM registrants)
    • Device resource definition update? (+DeviceDefinition, DeviceInstance, etc.)
    • UDI update? (DAM, IG etc. etc. etc.)
    • Use Whova app to connect to the OO meeting.


  • Type your task here, using "@" to assign to a user and "//" to select a due date

Co-Chairs (Ken Fuchs, John Rhoads)




Fuchs/Tom Thompson


Paul Schluter





Martin Hurrell (AWG Co-Chair)


Chair: Chris Courville

(Scribe: John Garguilo, please review, edit, and update as needed)


September 2020 HL7 Election Results:

  • (for HL7 DEV Co-Chairs): Todd Cooper, John Garguilo, John Rhoads
  • (for HL7 Anesthesia): Martin Hurrell

Congrats to Todd, John R, John G, and Martin

  • IEEE Disclosures: (Ken Fuchs)
  • Call for Potential Essential Patents Holders. Please contact IEEE WG co-chairs with just name and affiliation. 
  • IEEE - IEEE Patent Policy (Ken Fuchs)
  • Review of IEEE-SA Copyright Policy - IEEE Copyright Policy (Ken Fuchs)


  • Review of open Projects and PARs (Ken Fuchs)
  • PoCD
    • 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&
      • Bjorn Anderson made a motion "to accept PAR"


Terminology / Nomenclature (Paul Schluter)

  • LOINC Update (Dr. Swapna Abhyankar/NLM & Regenstrief)
    • Swapna provided an update regarding LOINC terminology and concept mapping activities
    • Paul Schluter asked about COVID terms -
      • Answer (by Swapna) - in general there is not specificity - but very challenging when to create new terms vs. using generic terms.
    • Work ongoing (weekly) with CDC, as well as ONC - published
    • Still publishing in an on-going fashion
    • Some funding was received related to COVID and included in the funding is working on concept maps… thus Swapna indicated work shall continue for the next year or so...
    • Reference: https://loinc.org/fhir/#conceptmap

10101 Update (Paul Schluter)

  • 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
    • Infusion Pump
  • 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)
    • See slide
    • 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 showed an on-line grammar parser/validator: Pegjs.org/online - Parser Generator for JavaScript
    • 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
    • Extends
  • 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: 

    1. between 10 and 20 additional detailed procedural use cases
    2. the specification of a 'clinical note' for each use case (effectively, fragments of the e-record)
    3. 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
    • Martin will take this as basis for moving forward…
    • Meeting cadence:  every other week? To progress
      • Martin is in favor of a virtual meeting every couple of weeks to once a month…
      • Todd mentioned possible repurposing some existing meetings.
      • Recommended that have a "Devices on FHIR' with "HL7 DEV" alternating… at 9 am.

Type your task here, using "@" to assign to a user and "//" to select a due date


Thursday, Q2

  • JOINT mHealth
  • NOTE:  This session will utilize the WebEx information above.
  • MH Update: cMHAFF, MHADE, SHIFT, EU Update (ISO/82304-2, mHealthHUB) (Graham / Botts / Datta / Ploeg)
  • RCC/MH TR Update (Makrodimitris / Fuchs / Datta)
  • MH Co-VID19 Battle Plan (Datta)

Gorra Datta, Matt Graham





Konstantinos Makrodimitris / Ken Fuchs / Datta


(Scribe: John Garguilo, please review, edit, and update as needed)

Joint Mobile Health Discussion

  • NOTE:  This session will utilize the WebEx information above.
  • Mobile Health WG Co-chairs: (Graham / Botts / Datta / Ploeg)
  • MH Update: cMHAFF, MHADE, SHIFT, EU Update (ISO/82304-2, mHealthHUB) (Graham)


  • Consumer Mobile Healthcare Application Functional Framework (cMHAFF)
  • https://cmhaff.healtheservice.com (cMHAFF)
  • Worked on several pilots
    • Good feedback regarding "shall", "should", etc. and how to code and evaluate the requirements
    • Children's Hospital of Philadelphia
      • Provided valuable feedback
      • Scoring across domains
  • Children's Health Fund - HRSA HITEQ (pilot in progress)
  • Frameworks are being define and constrained down for Igs
  • e.g., scoring criteria being considered…
  • Sample of U.S. Policies & Guidelines Assessed provided (see slides)
  • cMHAFF Web Guide (conformance based on SDU-v1)
  • CEN/ISO Health & Wellness Apps (multinational effort)
    • TS: ISO 82304-2 Health Software -- Part 2 Quality and reliability criteria for health and wellness apps
      • IEC 82304-1: Health coftware - part 1
      • IEC 62304 - Medical device software - software life cycle processess
    • Timeline:
      • Working Draft 2 published, WD 3 internal May - June
      • 30 November submission for publication



  • Mhealth Hub Project (Europe)
    • Attempting to collect healthcare systems of nation…
    • A EU project (not coming in directly from Stds body, but Stds body are involved in work through a knowledge hub space…)
    • Website referenced: https://mhealth-hub.org/


  • Mobile Health App Data Exchange
    • Target Audience: mobile health app developers
    • Beneficiaries: consumers providers and caregivers


  • RCC/MH TR Update (Makrodimitris / Fuchs / Datta)
    • "Remote Connected Care / Mobile Health Solutions for Interoperability in the Pandemic Era"
  • 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"
    • Remote Connecte Care & Mobile Health (RCC-MH)
    • Future Patient Care/Flow and Locations
    • Reference Slide Set
    • 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. 
    • Review of IEEE-SA Copyright Policy - IEEE Copyright Policy
  • IHE DEV DPI Program - Discussion / Decision (Cooper)
    • Monthly DPI Program deferred from Thursday to Friday due to these WGM's
    • Decision discussion will include the Gemini SDPi+FHIR "MDIRA/ICE Brief Profile Proposal" review & confirmation
  • Joint O&O / DEV Report Out


  • IEEE 11073 SDC (David Gregorczyk)

    • PKP & ModSpec standards (i.e., 11073-107xx)

 

  • PoCSpec Project Update and Review (Martin Kasparick (University of Rostock, Germany), Björn Andersen & Kathrin Riech (both University of Lübeck, Germany))

  • Click to add a new task...

John Garguilo






Todd Cooper




John Rhoads


David Gregorczyk


Martin Kasparick, Björn Andersen, Kathrin Riech

(Scribe: John Garguilo, please review, edit, and update as needed)

Garguilo Welcomed WG, reminded attendees to register Attendance, and provided a review of day's Joint HL7-DEV/IEEE PoCD Agenda

DEV F3 File Storage on Confluence

  • IEEE Disclosures: (John Garguilo)
    • Call for Potential Essential Patents Holders. Please contact IEEE WG co-chairs with just name and affiliation. 
    • IEEE - IEEE Patent Policy
    • Review of IEEE-SA Copyright Policy - IEEE Copyright Policy

IHE DEV DPI Program - Discussion / Decision (Todd Cooper)

  • Note: Monthly DPI Program Meeting deferred from Thursday to Friday due to these WGM's
  • Decision discussion will include the Gemini SDPi+FHIR "MDIRA/ICE Brief Profile Proposal" review & confirmation
    • Proposal (Tood Cooper)
      • Todd reviewed the final draft of the "IHE MDIRA Brief Profile Proposal" (download proposal here)
      • Motion by Todd Cooper to "move forward with MDIRA proposal"
        • First by John Rhoads, seconded by Chris Courville
        • Motion passed 21-0-0
      • Note: Proposal is posted on Confluence S3  and also sent to IHE-DEV WG (which will be meeting for Fall Virtual in early October 2020)


O&O Report out from Joint Meeting held during Q1 on Thursday, September 24, 2020 (John Rhoads)

  • See meeting minutes from O&O proceedings on Thursday, Sept 24, 2020, Q1 (Joint w HL7-DEV) and copied below
  • Discussion on device resources
  • 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):
    • Call Status

      This is a call in a recurring sequence (and occurs every week )

      Participation Information

      Phone Number: +1 929-436-2866
      Participant Passcode: 510 046 7805

      Web Meeting Info

      Join Zoom Meeting - https://zoom.us/j/5100467805 | Meeting ID: 510 046 7805 | +1 929-436-2866-US (New York) | Find your local number: https://zoom.us/u/acrJHLNHol
  • Device.Type shall now have a cardinality  0..* (which was approved by O&O) - this allow Device.specialization
  • John Rhoads suggested having a position paper to support discussion when working with O&O
  • Action (John R.) - arrange meeting to settled issues related to Device resource which should include the 20601

(The following was reproduced from O&O meeting minutes on Thursday, Sept 24, 2020, Q1 (Joint w HL7-DEV)):

  • Device/DeviceDefinition/DeviceMetric
    • 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.
  • Specialization/Capability/Property
    • Concerns with overlaps.
    • Proposal:
      • 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 
    • Further Proposal
      • Collapse into Property.


IEEE 11073 SDC 

PKP & ModSpec standards (i.e., 11073-107xx) (Dr. David Gregorczyk, Draeger)

  • Please see David's "2020-09-25_P11073_10700.pptx" slide set 
    (also on HEV S3 Connector Site)
  • Introduction
    • PKP Introduction and
    • 20701 + 20702
    • Concepts of the SDC core standards
  • Please join weekly  meetings if interested… Tuesdays 10 AM (Eastern)
    • SDC Core Standards
      • Layered set of standards (see slide 3)
      • Service Oriented Fashion
      • Service Discovery, Interface description, Messaging, Security, Event propagation
      • Streaming, Safe Data Transmission
      • Domaine and message Model + Device-specific extensions
      • Application-specific + Service-oriented
      • David showed the "SDC cathedral window" which show the set of standards which enable interoperability based Core Standards, Key Purposes, Device Specializations, and Nomenclature over all parts
        •  Organized in four concept areas (see slide 4)
      • David provided definitions for SDC terms used (e.g., SDC participant, system, service provider, service consumer)
      • Typical Conventional Medical Devices shown (slide 7) and various boundaries (and combinations) (slide 8)
      • Motivation of PKP was to set of requirements based on risk management and security attributes - thus any manufacture that are compliant to PKP standards - become "trusted" by other manufactures
      • Base PKP -10700
        • System functions and system function contributions
          • Function provided by a system of SDC participants that are connected by a medical IT network
          • Building blocks of system function and system function contributions - (see slide 12)
          • Example: Ventilator + C-arm shown (slide 13) - temporarily stopping ventilation while recording x-ray (with plug & trust for safe & secure integration and with risk management).  PKP certificate allows one device to "trust" another…
        • Safety & essential performance standard indication
          • System functions may come with specific safety and essential performance requirements
          • A manufacturer of an SDC service provider is aware of the requirements…,
          • e.g, particular standards that apply to the SDC service provider
      • SDC participant ensembles
        • Condition under which an SDC participant is permitted to execute a system function with another SDC participant
          • Base PKP provides the technical framework
        • No assumption on how the ensemble context sate information is retrieved
          • Inference of location and patient context states are available
      • The latest draft will be uploaded to IEEE-SA iMeet central site.
      • Change Proposal for 10700 PAR
        • Occurred to authors that the scope was not
        • Propose of change of Title (erasing the word "common") as base PKP lists "common" requirements, whereas the "Base" is expressive enough…(Slide 16)
        • Old scope, New scope proposed eliminates verbiage - more accurate and clear - does list defined terms in the scope statement
  1. Comment from Todd: perhaps eliminate the capitalization
  2. Get the word "products" in the scope - e.g., "system of products" vs. a "component within a given product"
  3. Words "safe effective and secure" - the main concern here is "safe" from the manufacturer (effective and secure is not the focus of this specification - which are achieved by other means
  • David had question of who to provide proposal request to?

Answer: PoCD 11073 WG Chair (John Rhoads and/or Secretary John Garguilo)


PoCSpec Project Update (Martin Kasparick, University of Rostock, Germany)

  • See Martin's Presentation (on HL7 DEV S3 Connector Site):
  • Need a good balance of "Strict" but enable individual manufactures extensions and innovation
  • Key goal: Safe and effective interchangeable medical devices
  • https://sourceforge.net/p/pocspec/tickets/10
  • PoCSpec Models - development process described (see slide 4)
    • First three steps are completed, currently working on defining semantics and last two items shown on slide
  • Proposed Outputs:
    • Standards document
    • + machine readable/interpretable model --> XSD (+ Schematron, if necessary)
    • + tooling-friendly representation --> ReqIF (Requirement exchange formats)
  • Concept of ModSpec - P11073-10720
    • Collection of sub models or containment trees used by multiple/diriment kinds of devices
    • Example: Idea is to put "user interface settings (e.g., language, brightness, volume, etc.)" into a ModSpec
    • Collection of these models to be used in DevSpecs or even by 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. → New Title "Suction and Irrigation Pump"
    • Motion made by Martin Kasparick to "Change Title and Scope statement of P11073-10725",  second by Bjorn Anderson
    • Motion passed 22-0-0

Introduction into the DevSpec Draft IEEE 11073-10721: High Frequency Surgical Equipment

  • 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"
      • Martin showed "Active Output Terminal" from standard IEC 60601-2-2 → This is the part of the device where the active accessory is connected, not the user interface.
      • 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 → Will be done when definitions are stable
  • 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
    • MVC-Pattern has to be used: 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

Carry-over DEV topics for next meeting(s)

Review of Projects not done, Status

(See: http://www.hl7.org/Special/committees/healthcaredevices/projects.cfm)

  • 3-year plan now no longer needed 
  • Projects reviewed (from prior meeting) from HCD HL7 Projects wiki page
    • 1568: no update (HCD is Co-Sponsor)
    • 1351: To be deleted from Project List (3 year plan no longer needed)
    • 1335: On-going (HCD is Co-Sponsor), owe an update to Project Insight (ballot item)
    • 1277: Need to update the PSS for the steering division (and update dates)
    • 1153: HCD is working with Anesthesia WG to get two groups revised, then Anesthesia WG has to complete DAM 
    • 898: Now at the next stage of usability (no needs for HCD from lead) - success!
    • 897: Now at the next stage of usability (no needs from HCD from lead) - success!
    • 850: Dependent on the DAM finishing
    • 513: HCD has asked to remove, still shows up 













Action items