- (Approved on 02/04/2020)as recorded & presented (motion made by John Garguilo, 2nd by Michael Faughn; approved 12-0-0); refer to Meeting Minutes (February, 2020, Sydney Australia ).
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.
Group going forward is to use Confluence for attendance, meeting agenda and meeting minutes/notes. Encouraged attendees to get an account at HL7 Confluence Page, click "Request an Account".
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):
Functional Endoscopic Sinus Surgeryu (FESS)
Quiet Hospital / Silent Point-of-Care
JHU/APL MDIRA/ICE for Military & Disaster Casualty Care
Preeclampsia During Pregnancy (PDP) - Care Coordination from Home to Clinic to Hospital
"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.
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 …
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…
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
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
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.
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&
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...
(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
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:
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.
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))
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 )
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 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
Comment from Todd: perhaps eliminate the capitalization
Get the word "products" in the scope - e.g., "system of products" vs. a "component within a given product"
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)
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
