Please join our RTM tcon this Wednesday, June 23rd, starting at 11:00 AM CDT - representation of Selectable Adjuncts

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, June 23rd, starting at 11:00 AM CDT.

We will be discussing a minor enhancement regarding how the ISOMode and SelAdjuncts are submitted by vendors to declare how their proprietary ventilation modes are mapped to ISO 19223 and included in IEEE P11073-10101b.  The proposed enhancement provides vendors with a greater degree of precision regarding how ISO 19223 Selectable Adjuncts are expressed in ISOMode and SelAdjuncts.  The proposed enhancement is fully compatible with the proposed ISO 19223 mode identifiers that have already been submitted by Draeger, Getinge and GE.  

The need for the enhancement became apparent while compiling the consolidated list of ventilator modes for all vendors, and in particular, for Non-invasive Ventilation (NIV).  In ISO 19223, NIV is normally classified a Selectable Adjunct but for ventilators intended for NIV only, it may be classified as a permanently active NIV adjunct.  NIV may also be expressed as an Operational Mode.

Although it is generally desirable to avoid multiple expressions for the same concept (i.e. “Non-invasive ventilation has been selected”) it is not the end of the world as far as interoperability goes, and nobody has expressed major concerns about it (as of yesterday).

 

Additionally, some vendors (e.g. GE) may view NIV as an essential property of their NIV ventilation mode and believe it should be expressed by ISOMode and not by the ‘lesser’ SelAdjuncts flag.  Another vendor (Draeger) don’t appear to be too concerned about expressing it as a SelAdjuncts flag.  Other vendors (e.g. Getinge) may simply prefer to convey all SelAdjuncts in the main ISOMode (MDC_VENT_MODE_ISO_19223) string and avoid using a separate SelAdjuncts (MDC_VENT_MODE_SEL_ADJUNCTS_ISO_19223) Boolean flag altogether to simplify mapping.

Allowing vendors to allocate some (or all) the their Selectable Adjunct(s) in either ISOMode or SelAdjuncts or both solves this issue.  I have updated the XSLT to allow the Selectable Adjuncts to be entered in this more flexibly precise manner.  We can, of course, provide guidance to vendors as we have in the past.  Data consumers (EMRs, clinical apps) would process ISOMode and SelAdjuncts, as before, namely that the effective value of Selectable Adjuncts is the logical-OR of ISOMode and SelAdjuncts, if both are present.  

Another way of stating this that ISOMode and SelAdjuncts, when combined with the logical-OR operation, is equivalent to its original ISO 19223 string representation.

To indicate this in the summary charts, a black square ■ would indicate a Selectable Adjunct conveyed by the main ISOMode string and black circle ● would indicate a Selectable Adjunct conveyed as a SelAdjuncts Boolean flag.  For the GE NIV mode shown below, (NIV) would be conveyed as a pre-coordinated SelAdjunct in the main ISOMode string whereas the TRG (Trigger Compensation) would be conveyed as a SelAdjunct that could be turned on and off while retain the same ISOMode.

Vendor

VendorMode

ISOMode

SelAdjuncts

TC

CC

LC

NIV

SIGH

TRG

FGF

Notes

NoteDetails

GE

NIV

CSV-PS <ACAP> (NIV)

TRG

○

○

○

■

○

●

○

The upshot of all of this is that the indication of NIV can be done several ways, in accordance with ISO 19223 while also supporting some vendor preferences.  The only downside to supporting multiple representations is that determination of whether NIV is in use or not requires that the receiving application must examine three sources of this information:  ISOMode, SelAdjuncts and Operational Mode for the presence of ‘NIV’ in any.

I believe this will flexibly satisfy everyone’s needs and preferences.  We would still be able to provide additional guidance (see 3.1.15 NIV below) as well as enforceable PEGjs and other constraints.

I look forward to our discussion tomorrow, and hope that you will be able to join.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

ISO 19923 §3.1.15

NIV

non-invasive ventilation

positive-pressure ventilation without the use of an invasive airway device

Note 1 to entry: The connection to the patient is typically by means of a specially designed face or nasal mask.

Note 2 to entry: The provision of NIV does not, in itself, require dedicated ventilation-modes although some might be more suited to its use, but it does typically require certain compensating measures, particularly those relating to the possibility of increased and variable leakage. These can include, added, extended or deactivated compensations, modified alarms limits, the deactivation of some alarms and the modification of inflation initiation and termination criteria.

Note 3 to entry: On ventilators intended for NIV only, these compensations are classified as a permanently active NIV adjunct. On ventilators where the compensations made to suit NIV are selectable as an option, although also adjunctive in their actions, these have been typically classified as an NIV ventilator operational mode.

[Paul Schluter]

Resending with Webex info below.

RTM Webex Meeting Information

Meeting number (access code): 145 134 2502 Meeting password: Devices1 Occurs every Wednesday effective Wednesday, September 2, 2020 from 11:00 AM to 12:00 PM, (UTC-05:00) Central Time (US & Canada) 11:00 am  |  (UTC-05:00) Central Time (US & Canada)  |  1 hr Join meeting Tap to join from a mobile device (attendees only) 1-866-469-3239,,1451342502## Call-in toll-free number (US/Canada) +1-650-429-3300,,1451342502## Call-in number (US/Canada)   Join by phone 1-866-469-3239 Call-in toll-free number (US/Canada) 1-650-429-3300 Call-in number (US/Canada) Toll-free calling restrictions Join from a video system or application Dial 14513...@ihe.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial 1451342...@lync.webex.com

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 30th, is cancelled.

Due to vacations and other scheduling conflicts we were unable to get enough people together this week but hopefully next week we will be able to do so.  In the meantime, we will continue our discussions by email.

Best regards, and have a safe and effective July 4th (Independence Day) in the United States!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

On Jun 22, 2021, at 4:51 PM, Paul Schluter <pssch...@gmail.com> wrote:

RTM Webex Meeting Information Meeting number (access code): 145 134 2502

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 7th, is cancelled.

Vacations and other scheduling conflicts have made it difficult to resolve the single remaining issue (representing <ACAP*> only in the main systematic ISOMode string and/or vendor Notes) so we will have to try again next week or conclude our discussions by email.  Once this is resolved, we will be able to assign numeric codes for the IEEE P11073-10101b Group6 ventilator mode terms that currently includes Draeger, Getinge and GE (we can always add other vendors at a later date, after they map their proprietary modes to the ISO 19223 representation).

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, July 14th, starting at 11:00 AM CDT.

I am very happy to say that we have resolved the remaining issues regarding the use of Notes for representing <ACAP*>.  The XSLT has been updated to create the penultimate set of tables that will define the IEEE P11073-10101b Group6 ventilator mode terms based on the ISO 19223 ventilator mode syntax and vocabulary.

The material is based on the substantial contributions by Draeger, Getinge and GE Healthcare and has undergone significant review by the vendors and the leadership of the ISO 19223 standard, especially by Drs. Norman Jones and Steven Dain, MD.  I would also like to thank Anders Häggström of Getinge regarding how <ACAP*> can be represented.  I plan to provide an overview of this effort during today's RTM call.  This work demonstrates that "we can do the impossible” given enough time, talent and energy.

Here’s a synopsis of the primary content in the attached set of three HTML tables:

Table 1:   This table lists vendor modes for Draeger, Getinge and GE, along with mappings to the ISO 19223 mode string and IEEE 11073 REFID.  This table will be included in IEEE P11073-10101b and can be extended with contributions from other vendors.

Selectable Adjuncts that are permanently associated with the VendorMode are pre-coordinated into the ISOMode string and the IEEE 11073 REFID.  Selectable Adjuncts that are conveyed as Boolean flags are listed in the SelAdjuncts column.  Receivers shall construct the logical-OR of ISOMode and SelAdjuncts to determine the overall Selectable Adjunct state and, if needed, to construct the overall canonical ISO Mode string.

The { TC, CC, LC, NIV, SIGH, TRG, FGF } columns provide a Boolean flag bit view of the Selectable Adjuncts for each VendorMode that are strictly derived from ISOMode (indicated by ⦿) and SelAdjuncts (indicated by ●).

The Notes and NoteDetails columns list the notes that are associated with each mode.  The original vendor note reference numbers have been consolidated as Notes starting at 10, reserving Notes 1 - 9 for future vendor-independent Notes.  For traceability, the original vendor note numbers are listed in the vNote column.

Column	Description/Notes
Vendor	Vendor [and optional Model suffix, e.g. GE-R860]
VendorMode	Vendor mode
VendorModeShortDescription	Vendor mode short description  (not shown, need Draeger info)
ISOMode	ISO 19223 string, including SelAdjuncts and consolidated Note numbers associated with mode
REFID	IEEE 11073 REFID
CODE10	CODE10 (final PART, CODE10 and CF_CODE10 assigned on July 23 for RTMMSv2)
SelAdjuncts	Selectable Adjuncts conveyed as Boolean flags
TC	Tube compensation  (output only)
CC	Compliance compensation  (output only)
LC	Leakage compensation  (output only)
NIV	Non Invasive Ventilation  (output only)
SIGH	SIGH mode (Draeger)  (output only)
TRG	Trigger compensation (GE)  (output only)
FGF	Fresh gas flow (GE)  (output only)
vNotes	Original Vendor Note reference numbers (will not appear in standard)
Notes	(0..*) Note References  (white-space separated consolidated Note numbers)
NoteDetails	(0..*) Note Details  (⬩ separated strings)

Table 2:   This table lists the ISOMode and equivalent IEEE 11073 REFID, and includes Selectable Adjuncts and consolidated Note numbers permanently associated with the mode.  This table will be included as normative content in IEEE P11073-10101b and can be extended.

Column	Description/Notes
ISOMode	ISO 19223 string, including SelAdjuncts and consolidated Note numbers associated with mode
REFID	IEEE 11073 REFID
CODE10	CODE10 (final PART, CODE10 and CF_CODE10 assigned on July 23 for RTMMSv2)
Notes	(0..*) Note References  (white-space separated consolidated Note numbers)
NoteDetails	(0..*) Note Details  (⬩ separated strings)

 

Table 3:   This table lists the consolidated Note number and details associated with the Note.  This table will be included as normative content in IEEE P11073-10101b and can be extended.

Column	Description/Notes
Note	Note Reference number (consolidated)
NoteDetails	Note Detail

In addition to the three tables, most of the material in the <<VentModeISO.5x…docx>> series of write-ups and other supporting material will be adapted and included in IEEE P11073-10101b to provide a largely stand-alone treatment of this set of terms, along with references to key sections of the ISO 19223 standard.

Due to summer vacations and other schedule conflicts, some of you may not be able to attend today’s meeting at 11:00 AM CDT.  I will be happy to schedule an additional meeting at a different date and time.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<ISO-Filter.1f.x3h.2021-07-13T20.html>>

[Paul Schluter]

Charles and colleagues,

The IEEE 11073 bit flags date back from ISO/IEEE 11073-10101-2004, nearly twenty years ago.  A significant amount of innovation in ventilators has occurred since then, and many view a bit flag representation (or pre-coordinated enumerations of bit flags) as inadequate for expressing the sophisticated ventilation modes that are used in present-day devices.

The ISO 19223 standard adopted a more sophisticated representation of ventilator mode using a structured text string.  It can support a pre-coordinated sequence of hierarchical concepts that provides a rigorous foundation that can express present-day ventilator modes and provide a framework for future extensions.  The IEEE 11073 work has adopted the ISO 19223 syntax and semantics in an essentially verbatim manner and supports round-trip transformation of the ISO 19223 string to IEEE 11073 REFIDs and back again.  Furthermore, we developed a PEGjs grammar that can be used to validate the ISO 19223 strings proposed by vendors.

I believe that the ISO 19223 string representation can represent the bit flags you have listed below, but it is imperative that you and your colleagues work directly with the ventilator manufacturers to ensure that the mapping to ISO 19223 is correct without going through a derivative and potentially ‘lossy’ bit flag representation.  [In some cases, e.g. hfv, hfjv and hfo, concepts were combined into a single HFV to conform with contemporary ISO conventions and standards.]

The attached set of notes provides additional detail and background regarding the reasons that we based the IEEE P11073-10101b work on the ISO 19223.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<Why ISO 19223 Ventilator Mode.2021-07-15T15.docx>>

On Jul 14, 2021, at 9:13 AM, <cha...@interopehealth.com> <cha...@InteropeHealth.com> wrote:

Paul,

 

I will unfortunately be in flight between the USA and France at the time of our t-con.

 

I have one input for the group:

When looking at all of those ventilation modes and how they map to the various vendor modes labelling, I see great analysis and progress.  However, this does not connect with the most important goal which is to express the enumerated values for the ventilation mode in a standardized way.

 

In IEEE 11073, there is a practical approach with a “32 bit map”, where one bit represents each elementary mode.  That way combining mode, when applicable can be easily represented.  By assigning REFID to each mode is fine, but assigning one bit in that 32 bit array is equally important.  The current list in IEEE 11073 2019 draft is:

vent-mode-spont(0),
vent-mode-cpap(1),
vent-mode-bipap(2),
vent-mode-ippw(3),
vent-mode-cmv(4),
vent-mode-irv(5),
vent-mode-imv(6),
vent-mode-simv(7),
vent-mode-insp-assist(8),
vent-mode-press-release(9),
vent-mode-psv(10),
vent-mode-mmv(11),
vent-mode-prop-assist(12),
vent-mode-hfv(13),
vent-mode-hfjv(14),
vent-mode-hfo(15),
vent-mode-peep(31)

 

In your table I see some of those modes, but some are never mentioned, others are not listed.

Am I getting concern for a non-issue ?

 

If the group can address this point, this would be great.

Now leaving for the airport.

 

Charles

 

 

De : ihepc...@googlegroups.com <ihepc...@googlegroups.com> De la part de Paul Schluter
Envoyé : mercredi 14 juillet 2021 09:56
À : ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>; device...@lists.hl7.org
Cc : Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net) <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Stefan Schlichting <stefan.sc...@ornet.org>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; STEVEN DAIN <sd...@rogers.com>; Jan Wittenber <jan.wi...@gmail.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Abhyankar, Swapna <sabh...@regenstrief.org>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <johnr...@johnrhoads.net>; Chris Courville <ccou...@epic.com>; michael.faughn <michael...@prometheuscomputing.com>; Tom.Ko...@bbraun.com; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; Michael J. Kirwan <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Mikael Petrini <mikael....@getinge.com>; Jeff Rinda <jeffre...@gmail.com>; Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>; snich...@gmail.com; Paul Schluter <pssch...@gmail.com>
Objet : [ihepcdtech:3158] Please join our RTM tcon today, Wednesday, July 14th, starting at 11:00 AM CDT - consolidated ventilator mode lists for Draeger, Getinge and GE

-- 
You received this message because you are subscribed to the Google Groups "IHE PCD Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihepcdtech+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihepcdtech/4C8BCCD1-B517-474A-8A17-CFED5F5D4B10%40gmail.com.

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, July 21st, starting at 11:00 AM CDT.   

For today, will will start out with how non-invasive ventilation (NIV) should be represented:

(1) only be pre-coordinated into the main ISOMode string,

(2) only be Boolean flag in SelAdjuncts, or

(3) represented either way, using the logical-OR of ISOMode and SelAdjuncts to determine the effective { TC, CC, LC, NIV, SIGH, TRG, FGF } Selectable Adjuncts.

Steve Dain recommends that it should sent only one way (1) or (2), citing possible risk management and safety considerations due to the flexibility of (3).  If we eliminate (3), however, then it will be difficult to support all vendor preferences, including the sensible expectation that the ISOMode should clearly indicate that (NIV) is supported.

I would be curious to hear your thoughts on whether (3) is a risk management and safety issue or not, based on your experience.

If we are unable to resolve this issue and/or if key participants cannot join today, I will try to set up another meeting and/or conclude our discussion by email.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<ISO-Filter.3j.2021-07-20T12.Draeger-NIV-trimmed.xls>>

Begin forwarded message:

From: Steven Dain <sd...@rogers.com>
Subject: Re: [IHE PCD ACM:1469] Please join our RTM tcon today, Wednesday, July 14th, starting at 11:00 AM CDT - consolidated ventilator mode lists for Draeger, Getinge and GE
Date: July 20, 2021 at 9:37:14 PM CDT
To: Paul Schluter <pssch...@gmail.com>, Norman Jones <n...@normansjones.com>, Paul Dixon <paul....@vyaire.com>, Anders Häggström <anders.h...@getinge.com>, Manfred Beier <manfre...@draeger.com>
Cc: "Tietz, Michael" <Michae...@draeger.com>, "Andersen, Bjoern" <bjoern....@draeger.com>, "Fuchs, Ken" <Ken....@draeger.com>, Paul Schluter <pssch...@gmail.com>
Reply-To: Steven Dain <sd...@rogers.com>

I'm ok if everyone indicates niv in the selAdjuncts instead of making it mandatory in the ISOMode.  We need one consistent place to identify that niv is being used. Risk management and  safety considerations dictate that we must be prescriptive in this use case due to the serious hazards if niv and invasive ventilation  get mixed up, particularly as many of the niv devices are managed remotely.

I do have a meeting at the same time but I'll try to join your meaning once I see the agenda for the other.

Best regards, 

Steven

Please excuse the typos

On Tue, Jul 20, 2021 at 15:49, Paul Schluter
<pssch...@gmail.com> wrote:
Steven and colleagues,

Although I agree with you that three sources of NIV information {ISOMode, SelAdjuncts and Operational Mode} may be one too many, we also need to avoid being overly prescriptive.

In my opinion, removing or ignoring “NIV” in Operational Mode to obtain ventilation mode is a sensible idea; we should only use ISOMode and SelAdjuncts to convey overall ventilator mode.  This pair of observations (or settings) is very similar to how existing ventilation mode is sent today.

Using ISOMode and SelAdjuncts, and combining the Selectable Adjunct information using a logical-OR operation, will remain “as is” - it provides an additional degree of flexibility for vendors to express their ventilation modes using ISO 19223 in a manner consistent with their existing design conventions, philosophies and documentation.

That said, of all the Selectable Adjuncts we have considered so far, requiring that (NIV) be expressed in the main systematic ISOMode (rather than as a SelAdjuncts Boolean flag) would also be a sensible idea.  In most of the systems I have reviewed, a non-trivial number of ventilator characteristics are associated with (NIV) operation, whereas most of the other Selectable Adjuncts have far fewer settings associated with them.

The only downside when including (NIV) in the main systematic ISOMode is that it increases the number of permutations.  Although this is not an issue for Getinge and GE, it increases the number of distinct ISOModes (and IEEEModes and associated REFIDs and numeric codes) from 35 to 62 distinct modes, out of a total of 136 modes if all Selectable Adjuncts were pre-coordinated in the ISOMode and IEEEMode strings.

I have attached an Excel file that illustrates this, starting with the current total of 35 distinct Draeger ISO/IEEE Modes when all Selectable Adjuncts are conveyed as Boolean flags in SelAdjunct (columns vISOMode and vSelAdjuncts) which increases to 62 distinct Draeger ISO/IEEE Modes if (NIV) is conveyed by the main systematic ISOMode string (columns nvISOMode and nvSelAdjuncts).  [This uses the original Draeger vNote numbers.]

This represents a nearly 80% increase in the number of ISO/IEEEModes required to support the current list of Draeger modes.  Although this is not a big deal of computers and programmers, it is a lot more information for review and consumption, especially with the numerous duplicated base concepts.

We can discuss this during tomorrow’s (7/21) RTM tcon starting at 11:00 AM CDT.  I believe it is essential that representatives from Draeger attend as well as Steven Dain attend, so if tomorrow at 11:00 CDT AM doesn’t work out, an alternative time and teleconference service will need to be arranged or we will just have to continue this discussion by email.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<ISO-Filter.3j.2021-07-20T12.Draeger-NIV-trimmed.xls>>

On Jul 19, 2021, at 9:38 AM, Steven Dain <sd...@rogers.com> wrote:


Is NIV a function of a ventilator that provides ancillary actions to a ventilator mode?  (19223 3.11.4)

ancillary=providing necessary support to the primary activities or operation of an organization, institution, industry, or system. 

or is NIV the primary activity?

Sorry for the profound philosophical question on a Monday

My concern is

"The upshot of all of this is that the indication of NIV can be done several ways, in accordance with ISO 19223 while also supporting some vendor preferences.  The only downside to supporting multiple representations is that determination of whether NIV is in use or not requires that the receiving application must examine three sources of this information:  ISOMode, SelAdjuncts and Operational Mode for the presence of ‘NIV’ in any.[SD1] "

I don't like this downside.  We need to make a decision and choose one of " ISOMode, SelAdjuncts or Operational Mode".   I think will need to be practical here rather than philosophical.  I'll leave it up to the manufacturers to choose the one.  Personally I like the (NIV) in the ISOMode string and would include it in the Draeger ISOModes, like you did for the Getinge and GE.

I'll request Nihon Koden, Medtronic, Thornhill Research and Vyaire to complete their tables once we have settled on this issue.  Paul Dixon will have time now that he has finished ISO 4135  





Please find my attached document for a few other, I think non-controversial edits.

Thanks for this Paul S!  Well done.


Steven Dain

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 28th, is cancelled.  With the exception of one item, all the new 10101b Group6 terms related to ventilation mode are ready for final “provisional” numeric code assignment.

This includes any and all changes related to Selectable Adjuncts and how they are represented in the main <ISOMode> string, IEEE 11073 REFID and numeric code conveyed by MDC_VENT_MODE_ISO_19223, based on vendor determination of the Selectable Adjuncts that are “inherent to the mode”.  All Selectable Adjuncts, both “inherent to the mode” and as runtime selections, are now listed in the <SelAdjuncts> column and are conveyed by MDC_VENT_MODE_SEL_ADJUNCTS_ISO_19223 as Boolean flags.

The only remaining item is to incorporate the <VendorModeShortDescriptions> associated with <VendorMode>.  I am happy to say that all the information is now ‘in hand’ pending final review by one vendor.  As soon as that is completed, I will send out the update list with the <VendorModeShortDescriptions> by the end of this week so that everyone has time to review it prior to our RTM tcon on August 4th.

I would like to thank Anders Häggström, Ken Fuchs, Eldon Metz, Kim Brauer, Michi Tietz, Steven Dain, Norman Jones and John Walsh for their participation in the call last week and expert contributions throughout this endeavor.  We’re just about done!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, August 4th, and next Wednesday, August 11th, are cancelled.  I have not received a final confirmation of the <VendorModeShortDescriptions> from one vendor and I will be on vacation next week in Door County.

With so many people out on vacation this month, it makes it nearly impossible to complete multiple internal reviews, especially on something complex like ventilator mode.

Best regards, and I will see you in a few weeks!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

I am happy to say that we now have <VendorModeShortDescriptions> for all three vendors and these have been incorporated into the attached HTML tables for the 10101b Group6 ventilator modes.  The tables also incorporate other changes and additions since the previous ventilator mode listing that I sent to you on July 14.  The most notable changes include:

1.  The <ISOMode> string and associated IEEE 11073 <REFID> only include Selectable Adjuncts that are considered ‘inherent’ to the associated mode by the vendor, and <SelAdjuncts> includes all Selectable Adjuncts, both ‘inherent’ to the mode and conveyed as Boolean flags.

2.  A <VendorModeShortDescription> is provided for each distinct ISOMode, and in some cases, with combinations of Selectable Adjuncts expressed as Boolean flags.

3.  Row order is specified by the vendor.  This includes rows having the same ISOMode but different combinations of Selectable Adjuncts expressed as Boolean flags.  This allows the modes to be listed in a sensible clinical and tutorial order and will simplify review and updates later on.

 

4.  At the present time, we will not require that vendors provide ISOMode mappings for the { ApneaVentilation, BackupVentilation, or FailSafeVentilation } states conveyed by MDC_VENT_OPERATIONAL_STATE.  This information has been difficult to obtain and it is often not conveyed with the clarity of the OperationalMode, which has been the primary focus of the ISO 19223 and IEEE 11073 efforts.

Although <VendorModeShortDescription> will be useful for searching and providing additional information about the ventilation modes for each vendor, it may be difficult to include this highly vendor-specific information in the published IEEE 11073 and ISO/IEEE 11073 standards later on, due to the reluctance of SDOs to include vendor-specific information in the standard.  That said, the Vendor and VendorModes will be included in the published standards and we certainly plan to include <VendorModeShortDescription> in RTMMSv2, where it would be searchable.

Please take this opportunity to review this material over the next few weeks.  After I return from vacation, we could consider having an RTM tcon on Wednesday, August 18th, or possibly later, depending on everyone’s schedules.  We should be in a good position to assign final numeric codes by the end of August, depending on any feedback we receive.  In the meantime, exchanging email comments will work just fine.

Thanks for all your help, and best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<ISO-Filter.2d.x3m.2021-08-05T21.html>>

On Jul 14, 2021, at 8:55 AM, Paul Schluter <pssch...@gmail.com> wrote:   August 7 updates shown with red font

Greetings!

Please join our RTM tcon this Wednesday, July 14th, starting at 11:00 AM CDT.

I am very happy to say that we have resolved the remaining issues regarding the use of Notes for representing <ACAP*>.  The XSLT has been updated to create the penultimate set of tables that will define the IEEE P11073-10101b Group6 ventilator mode terms based on the ISO 19223 ventilator mode syntax and vocabulary.

The material is based on the substantial contributions by Draeger, Getinge and GE Healthcare and has undergone significant review by the vendors and the leadership of the ISO 19223 standard, especially by Drs. Norman Jones and Steven Dain, MD.  I would also like to thank Anders Häggström of Getinge regarding how <ACAP*> can be represented.  I plan to provide an overview of this effort during today's RTM call.  This work demonstrates that "we can do the impossible” given enough time, talent and energy.  I would also like to thank Thomas Kreuger and Michi Tietz (Draeger), Anders Häggström (Getinge) and Kim Brauer and Mike Krajnak (GE) for their contributions regarding <VendorModeShortDescription>.

Here’s a synopsis of the primary content in the attached set of three HTML tables:

Table 1:   This table lists vendor modes for Draeger, Getinge and GE, along with mappings to the ISO 19223 mode string and IEEE 11073 REFID.  This table will be included in IEEE P11073-10101b and can be extended with contributions from other vendors.

Selectable Adjuncts that are permanently associated with the VendorMode are pre-coordinated into the ISOMode string and the IEEE 11073 REFID.  All Selectable Adjuncts, both ‘inherent’ to the mode and that are conveyed as Boolean flags are listed in the SelAdjuncts column.

The { TC, CC, LC, NIV, SIGH, TRG, FGF } columns provide a Boolean flag bit view of the Selectable Adjuncts for each VendorMode that are pre-coordinated in the ISOMode (indicated by ⦿) or sent as Boolean flags (indicated by ●).

The Notes and NoteDetails columns list the notes that are associated with each mode.  The original vendor note reference numbers have been consolidated as Notes starting at 10, reserving Notes 1 - 9 for future vendor-independent Notes.  For traceability, the original previous vendor note numbers are listed in the vNote column.

Column	Description/Notes
Vendor	Vendor [and optional Model suffix, e.g. GE-R860]
VendorMode	Vendor mode
VendorModeShortDescription	Vendor mode short description

ISOMode	ISO 19223 string, including ‘inherent’ Selectable Adjuncts and consolidated Note numbers
REFID	IEEE 11073 REFID
CODE10	CODE10 (final PART, CODE10 and CF_CODE10 assigned at end of August for RTMMSv2)
SelAdjuncts	All Selectable Adjuncts, both ‘inherent’ to the mode and conveyed as Boolean flags

TC	Tube compensation  (output only)
CC	Compliance compensation  (output only)
LC	Leakage compensation  (output only)
NIV	Non Invasive Ventilation  (output only)
SIGH	SIGH mode (Draeger)  (output only)
TRG	Trigger compensation (GE)  (output only)
FGF	Fresh gas flow (GE)  (output only)
vNotes	Original Vendor Note reference numbers (will not appear in standard)
Notes	(0..*) Note References  (white-space separated consolidated Note numbers)
NoteDetails	(0..*) Note Details  (⬩ separated strings)

Table 2:   This table lists the ISOMode and equivalent IEEE 11073 REFID, and includes Selectable Adjuncts and consolidated Note numbers permanently associated with the mode.  This table will be included as normative content in IEEE P11073-10101b and can be extended.

Column	Description/Notes
ISOMode	ISO 19223 string, including ‘inherent’ Selectable Adjuncts and consolidated Note numbers
REFID	IEEE 11073 REFID
CODE10	CODE10 (final PART, CODE10 and CF_CODE10 assigned at end of August for RTMMSv2)

Notes	(0..*) Note References  (white-space separated consolidated Note numbers)
NoteDetails	(0..*) Note Details  (⬩ separated strings)

 

Table 3:   This table lists the consolidated Note number and details associated with the Note.  This table will be included as normative content in IEEE P11073-10101b and can be extended.

Column	Description/Notes
Note	Note Reference number (consolidated)
NoteDetails	Note Detail

In addition to the three tables, most of the material in the <<VentModeISO.5x…docx>> series of write-ups and other supporting material will be adapted and included in IEEE P11073-10101b to provide a largely stand-alone treatment of this set of terms, along with references to key sections of the ISO 19223 standard.

Due to summer vacations and other schedule conflicts, some of you may not be able to attend today’s meeting at 11:00 AM CDT.  I will be happy to schedule an additional meeting at a different date and time.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

RTM Webex Meeting Information Meeting number (access code): 145 134 2502

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, August 18th, starting at 11:00 AM CDT.  

This will be a Q&A and general discussion regarding ventilator mode and related nomenclature topics.  If possible, please send me a short email regarding what you would like to discuss and I will try to send out a brief agenda prior to our tcon at 11:00 AM CDT.  Regardless of whether I receive any topics or not, I will hold the call open for at least ten minutes.

Since it is the middle of August, I’m not sure how many people can attend or what topics will be discussed.  There are several topics for which key people are on vacation, and we may not be able to make a final decision until they return.  That said, an open-ended discussion can still be very useful, and it certainly can be more interactive and faster than corresponding by email.

Best regards, and enjoy your summer!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Aug 7, 2021, at 12:38 PM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

I am happy to say that we now have <VendorModeShortDescriptions> for all three vendors and these have been incorporated into the attached HTML tables for the 10101b Group6 ventilator modes.  The tables also incorporate other changes and additions since the previous ventilator mode listing that I sent to you on July 14.  The most notable changes include:

1.  The <ISOMode> string and associated IEEE 11073 <REFID> only include Selectable Adjuncts that are considered ‘inherent’ to the associated mode by the vendor, and <SelAdjuncts> includes all Selectable Adjuncts, both ‘inherent’ to the mode and conveyed as Boolean flags.

2.  A <VendorModeShortDescription> is provided for each distinct ISOMode, and in some cases, with combinations of Selectable Adjuncts expressed as Boolean flags.

3.  Row order is specified by the vendor.  This includes rows having the same ISOMode but different combinations of Selectable Adjuncts expressed as Boolean flags.  This allows the modes to be listed in a sensible clinical and tutorial order and will simplify review and updates later on.

 

4.  At the present time, we will not require that vendors provide ISOMode mappings for the { ApneaVentilation, BackupVentilation, or FailSafeVentilation } states conveyed by MDC_VENT_OPERATIONAL_STATE.  This information has been difficult to obtain and it is often not conveyed with the clarity of the OperationalMode, which has been the primary focus of the ISO 19223 and IEEE 11073 efforts.

Although <VendorModeShortDescription> will be useful for searching and providing additional information about the ventilation modes for each vendor, it may be difficult to include this highly vendor-specific information in the published IEEE 11073 and ISO/IEEE 11073 standards later on, due to the reluctance of SDOs to include vendor-specific information in the standard.  That said, the Vendor and VendorModes will be included in the published standards and we certainly plan to include <VendorModeShortDescription> in RTMMSv2, where it would be searchable.

Please take this opportunity to review this material over the next few weeks.  After I return from vacation, we could consider having an RTM tcon on Wednesday, August 18th, or possibly later, depending on everyone’s schedules.  We should be in a good position to assign final numeric codes by the end of August, depending on any feedback we receive.  In the meantime, exchanging email comments will work just fine.

Thanks for all your help, and best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<ISO-Filter.2d.x3m.2021-08-05T21.html>>

On Aug 4, 2021, at 9:11 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcons for today, Wednesday, August 4th, and next Wednesday, August 11th, are cancelled.  I have not received a final confirmation of the <VendorModeShortDescriptions> from one vendor and I will be on vacation next week in Door County.

With so many people out on vacation this month, it makes it nearly impossible to complete multiple internal reviews, especially on something complex like ventilator mode.

Best regards, and I will see you in a few weeks!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Charles,

My comments in-line in red below.  We can discuss further during the RTM tcon today.

Paul

On Aug 18, 2021, at 8:42 AM, <cha...@interopehealth.com> <cha...@InteropeHealth.com> wrote:

Paul, 

 

Thanks so much for the great work and making you available in the middle of the summer.

 

Four questions :

1. I do not see the REFID and CF_CODE10 specified for the MDC_VENT_MODE_ISO_19223 and for the MDC_VENT_MODE_SEL_ADJUNCTS_ISO_19223.  Where is it in the attachments ?  The final codes have not been assigned since we have an open item (should FGF be a Selectable Adjunct or not) and possibly others to resolve, probably after next week’s 8/25 RTM tcon due to schedule/vacation conflicts.
2. IEEE 11073 seems incomplete in specifying the way the 32 BitMap was encoded.  For interoperability it is critical to be explicit between IHE DEC Profile and IEEE 11073.  How will the Selected Adjunct bitmap be encoded ? As a series of 7 digits with a 0 or 1 value ?  As an integer value between 0 and 255 corresponding to the 7 bits out of a byte (extensible) ? Other ?  Should we plan for the addition of other adjuncts in the future?  Can private bit be privately added ?  We could assign ASN.1 style bit names and numbers, in addition to the short tokens ‘TC', ‘CC', ‘LC', ‘NIV', ‘SIGH', ‘TRG', ‘FGF’ that we already have.  The vast majority if IHE PCD DEC HL7 V2 messages use the short token representation, and this information is captured in the hRTM “harmonized Rosetta” along with any synonyms, e.g. tokens, ASN.1-bits, OIDs.
3. Several vendor specific ventilation modes include values such as “standby” or “neonatal/pediatric/adult”.  Are those included in the newly defined REFIDs for ISOModes ?  I do not see them.  ’Standby’ is included as a special mode, along with several other special modes, in the PEGjs [5e] in the write-up I sent you earlier.  I believe we have a generic device "neonatal/pediatric/adult” selection, and we do have a generic sensor classification for "neonatal/pediatric/adult”.  Currently there are no plans to include it in the ISO 19223 and IEEE 11073 vent mode REFIDs unless that is everyone’s preference.
4. Will the vendor notes be included in the standard ?  It seems necessary as the vendor note numbers appear in the REFID.  Yes, they will, in an extensible table similar to HTML Table 3 in the listing.

 

Thanks so much.

 

Charles

 

De : ihepc...@googlegroups.com <ihepc...@googlegroups.com> De la part de Paul Schluter

Envoyé : mercredi 18 août 2021 14:54

À : ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>; device...@lists.hl7.org

Cc : Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net) <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Stefan Schlichting <stefan.sc...@ornet.org>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; STEVEN DAIN <sd...@rogers.com>; Jan Wittenber <jan.wi...@gmail.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Abhyankar, Swapna <sabh...@regenstrief.org>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <johnr...@johnrhoads.net>; Chris Courville <ccou...@epic.com>; michael.faughn <michael...@prometheuscomputing.com>; Tom.Ko...@bbraun.com; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; Michael J. Kirwan <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Mikael Petrini <mikael....@getinge.com>; Jeff Rinda <jeffre...@gmail.com>; Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>; snich...@gmail.com; Peeters, Wouter <w.pe...@philips.com>; Paul Schluter <pssch...@gmail.com>
Objet : [ihepcdtech:3165] Please join our RTM tcon today, Wednesday, August 18 - Q&A and general discussion regarding ventilator mode and related topics

-- 
You received this message because you are subscribed to the Google Groups "IHE PCD Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihepcdtech+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ihepcdtech/E3491561-7E57-4055-8275-C7BC9A21E259%40gmail.com.

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, August 25th, starting at 11:00 AM CDT.

This will be a final wrap-up of the ISO 19223 and IEEE 11073 ventilator modes for Draeger, Getinge and GE and proposed resolutions.  We will review the relatively minor changes have been made over the past two weeks, and I believe we are now at a point where we could finalize the proposed “provisional” numeric codes by the end of this week.

The changes relative to the previous <ISO-Filter.2d.x3m.2021-08-05T21.html> set of HTML tables include:

1.  The Selectable Adjunct tokens TRG and (TRG) have been changed to TRGC and (TRGC) to clearly indicate “Trigger compensation”.

Going forward, all “compensation” adjuncts will uniformly end with “C”, maintaining the convention established by the original ISO 19223 ’TC’, ‘CC’ and ‘LC’ tokens.  [This change affects some of the <ISOModes> and <SelAdjuncts> for Getinge and GE.]

2.  The Selectable Adjunct tokens FGF and (FGF) have been replaced by the complementary noFGFC and (noFGFC).   [Note the “C” for “compensation”.]

Since we are a reasonably certain that most, if not all, contemporary anesthesia machines either ‘compensate’ for FGF or, in the case of several Draeger models, use fresh gas decoupling, we should make the compensation or diversion of fresh gas flow the default expectation, and a Selectable Adjunct would not be shown in the common case.  If we later encounter an anesthesia machine that does not compensate nor eliminate this error, then the negative ’noFGFC’ would be used as the Selectable Adjunct to indicate this.

This modification only affects some of the <ISOModes> and <SelAdjuncts> for GE   The FGF and (FGF) indications for the GE-CS750 have been removed, and all three vendors (Draeger, Getinge and GE) are now consistent in this regard since they compensate for or otherwise divert the fresh gas flow so that the delivered volume is correct.  [Pending confirmation by one vendor.]  [I have attached a more detailed explanation below.]

3.  The two GE-R860 modes that were listed together in previous editions have now been split into separate but otherwise identical rows to match GE’s documentation.

That’s it, and I believe we are now ready to assign the proposed “provisional” numeric codes that will be submitted to Michael Faughn for his independent review and formal inclusion as “provisional” terms in RTMMSv2.  If you cannot join the call today please send any comments or concerns by email no later than Wednesday, August 25th.  If there are no showstopper issues, I plan to finalize the proposed “provisional” numeric codes by Friday evening, August 27th.

Thanks in advance for your thoughtful consideration.  I would also like to thank Norman Jones, Anders Häggström and Charles Parisot for a great discussion last week as well as the email discussions with Kim Brauer and Steven Dain and other experts who helped us finalize the last few remaining issues noted above.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<ISO-Filter.2e.x3n.2021-08-24T20.withISOtoIEEE.html>>

On Aug 24, 2021, at 11:07 AM, Paul Schluter <pssch...@gmail.com> wrote:  Re: FGF compensation - defining the negative of a Selectable Adjunct

Steven, Norman and John,

I would like to propose another method for indicating the absence or negative of a Selectable Adjunct, using the ‘FGF compensation’ as the primary example.

Before we proceed, let’s agree to append ‘C’ for ‘compensation’, thus changing ‘FGF’ to ‘FGFC’ or possibly to ‘FGC’.

Since we are a reasonably certain that most, if not all, contemporary anesthesia machines either ‘compensate’ for FGF or, in the case of several Draeger models, use fresh gas decoupling, we should make the compensation or diversion of fresh gas flow the default expectation, and a Selectable Adjunct would not be shown.  If we later encounter an anesthesia machine that does not compensate nor eliminate this error, then the negative ’noFGFC’ (or the shorter ’noFGC’) would be used as the Selectable Adjunct to indicate this.

This provides several benefits:

1.  It eliminates the need to indicate FGFC (or shorter FGC) by the three vendors (Draeger, Getinge, GE) since they all provide FGF compensation or diversion.

2.  If we need ’noFGFC’ (or the shorter ’noFGC’) later on, we can deploy it without affecting backwards compatibility.  It will be defined and supported in the PEGjs and XSLT but would not be displayed as an Selectable Adjuncts column until it is actually needed.

3.  Defining ‘noFGFC’ is more vendor-neutral, since the Draeger FGDV solves this issue directly without the need for a compensation calculation.

Note that adopting the negative ’noFGFC’ (or the shorter ’noFGC’) precludes the use of the positive ‘FGFC’ (or the shorter ‘FGC’) - you can’t have both the negative and positive representations since the absence of the token would be ambiguous.  If we adopt the negative ’noFGFC’ (or the shorter ’noFGC’) convention, then the presence of the ‘noFGFC' token indicates 'no compensation' whereas the absence of the ‘noFGFC' token indicates that 'the additional FGF is compensated for or diverted by the machine'.  This allows the Selectable Adjuncts to be encoded as a sequence of Booleans, indicated by the presence (true()) or absence (false()) of the token, and is supported by “classic” IEEE 11073, HL7 V2 and V3, FHIR, and other encodings.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

PS.  Steve, what have your found out from the ISO or other anesthesia standards regarding this topic?

[Paul Schluter]

Greetings!

The RTM tcon is cancelled for today, Wednesday, August 25th, due to the scheduling conflict with the IEEE EMBS Public Forum this week.  Sorry for the late change in plans!

We will continue our discussion next Wednesday, September 1st, starting at 11:00 AM CDT.  In the mean time, please follow up with any questions or concerns by email.

See you next week!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Aug 25, 2021, at 8:45 AM, Paul Schluter <pssch...@gmail.com> wrote:  Re: Please join our RTM tcon today, Wednesday, August 25 - penultimate list of ISO 19223 and IEEE 11073 ventilator modes for Draeger, Getinge and GE

[Paul Schluter]

Greetings!

The RTM tcon is cancelled for today, Wednesday, September 1st.  Many people are out on vacation this week and other IHE PCD meetings have been cancelled as well.

I am very happy to announce that we now have unanimous agreement that using the complementary ’noFGFC’ Selectable Adjunct is the best way to represent this information, especially since it will not need to be listed for the vast majority of contemporary anesthesia machines.  Provisional numeric codes for the ISO 19223 and IEEE 11073 ventilator modes for Draeger, Getinge and GE have now been assigned and were submitted last week to Michael Faughn for his independent code conflict review and incorporation in RTMMSv2.

We will continue our discussion next Wednesday, September 8th, starting at 11:00 AM CDT.  

See you next week!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Aug 25, 2021, at 8:45 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

Please join our RTM tcon this Wednesday, August 25th, starting at 11:00 AM CDT.   (this meeting was cancelled due to IEEE EMBS Public Forum last week)

[Todd Cooper]

FWIW - 

One of the proposals that has been on the table for a long time - awaiting someone's time & resources ... like MANY things in this area - is to add references per definition or at least in the section's introductory / overview information - to the technical / academic / standards that provide the detailed basis behind the nomenclature.  This would provide significant benefit to everyone in the community, but alas ... yet another dream ...

~>Todd 탇 

Soli Deo gloria

M:  +1 858.442.9200

S:  ToddCooperAFC

On Wed, Sep 1, 2021 at 7:19 PM Steven Dain <sd...@rogers.com> wrote:

Charles,

Please read ISO 19223 lung ventilator vocabulary and semantics or look on the ISO online browsing platform.  It is all explained well there.

Best regards,

Steven Dain

Please excuse the typos

On Wed, Sep 1, 2021 at 17:11, cha...@InteropeHealth.com

<cha...@InteropeHealth.com> wrote:

Paul,

 

Great Progress.  One suggestion.

 

In working on the ventilation modes, the descriptive text by Draeger is quite precise and clarifies each one of the major modes.

A similar level of documentation is missing for Gettinge and GE, where the vendor mode acronyms are simply spelled out.

 

Such a stronger documentation would really strengthen the standards.  Has this been discussed ?

 

Charles

 

De : ihepc...@googlegroups.com <ihepc...@googlegroups.com> De la part de Paul Schluter

Envoyé : mercredi 1 septembre 2021 16:27

À : ihe-p...@googlegroups.com; ihe-p...@googlegroups.com; PCD Technical Committee GG <ihepc...@googlegroups.com>; ihe-pcd-...@googlegroups.com; IHE-PCD-DPI-WG <ihe-p...@googlegroups.com>; device...@lists.hl7.org
Cc : Monroe Pattillo <monroe_...@bellsouth.net> (monroe_...@bellsouth.net) <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Stefan Schlichting <stefan.sc...@ornet.org>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; STEVEN DAIN <sd...@rogers.com>; Jan Wittenber <jan.wi...@gmail.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Abhyankar, Swapna <sabh...@regenstrief.org>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <johnr...@johnrhoads.net>; Chris Courville <ccou...@epic.com>; michael.faughn <michael...@prometheuscomputing.com>; Tom.Ko...@bbraun.com; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; Michael J. Kirwan <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Mikael Petrini <mikael....@getinge.com>; Jeff Rinda <jeffre...@gmail.com>; Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>; snich...@gmail.com; Peeters, Wouter <w.pe...@philips.com>; Paul Schluter <pssch...@gmail.com>

Objet : [ihepcdtech:3172] The RTM tcon is cancelled for today, Wednesday, September 1st. NEWSFLASH: Provisional numeric codes for the 10101b Group6 ISO 19223 and IEEE 11073 ventilator modes have now been assigned!

--

You received this message because you are subscribed to the Google Groups "IHE PCD Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihepcdtech+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ihepcdtech/D6586ECC-371C-4F60-ABE3-23D25FF571B2%40gmail.com.

[Michael Faughn]

Would be fairly easy to support in RTMMS...

--

Michael Faughn
Software Developer
Prometheus Computing, LLC
m.fa...@prometheuscomputing.com
Mobile: (828) 226-1369

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, September 8th, starting at 11:00 AM CDT.
 
I am very happy to announce that the final numeric codes have been assigned for the new 10101b Group6 ISO 19223 and IEEE 11073 ventilator terms and modes and have been successfully verified by Michael Faughn to ensure that there are no code assignment conflicts with any previous terms.  Micheal expects that they will be added to the RTMMSv2 as “provisional” terms later this month.

The material is based on the substantial contributions by Dräger, Getinge and GE Healthcare and has undergone significant review by the vendors and the leadership of the ISO 19223 standard, especially by Drs. Norman Jones, Steven Dain, MD and John Walsh, MD.  I would like to thank Michi Tietz, Manfred Beier, Thomas Krueger and Jan-Alrik Philipsen of Dräger; Anders Häggström, Per Johansson, Peter Verständig and Mikael Petrini of Getinge/Maquet; and Kim Brauer, Mike Krajnak and Steven Nichols of GE Healthcare who did the heavy lifting mapping their ventilator modes to ISO 19223 and ensuring that the mapping accurately represented the capabilities of their systems.

*     *     *

The IEEE P11073-10101b Group6 information is sent to you as two HTML files and derived Excel files for (1) the new ventilator terms and settings to support the ISO 19223 inspired information and (2) the list of vendor modes for Draeger, Getinge and GE and their mappings to ISO 19223 and IEEE 11073 REFIDs and numeric codes.  I have also provided a copy of the write-up assocated with the ISO 19223 to IEEE REFID mapping process for background.  This is a verbatim copy of the information to Michael Faughn on August 27th for his independent verification that there are no conflicts with existing terms and incorporation into RTMMSv2 as “provisional” terms.

New ventilator terms and settings

The format of the HTML file is otherwise the same as earlier 10101b Group4, Group5 and Group7 files.  I did not include the _SETTING über-discriminators, since earlier “classic” ventilator and infusion pump mode terms do not use them.  We will discuss this at the upcoming IEEE 11073 GC meeting, and the _SETTING variant can always be added at any time.

The columns for <AllTogetherGroup6.x4a.2021-08-27T14.isoVentMode-final.html/xls> are summarized below:

Column	Description/Notes
REFID	IEEE 11073 REFID
CommonTerm	IEEE Common Term
Acronym	IEEE Acronym
Description	IEEE Description/Definition
AlertType	(not used)
Disc	Discriminator Group
PartCode	PART :: CODE10
CF_CODE10	32-bit context-free code = (PART * 216) + CODE10
gp	10101b Group number  (for internal bookkeeping only)
UOM_MDC	(not used)
UOM_UCUM	(not used)
Enum_Values	Enumeration or bit-flag values
Enum_Descriptions	Enumeration or bit-flag descriptions
PEGjs	(not used – PEGjs for ISOMode will be documented in a separate section)

 

Vendor modes and mappings to ISO 19223 and IEEE 11073 REFIDs and numeric codes

The columns are described below for the three tables that comprise <ISO-Filter.2e.x3n.2021-08-27T10.isoVentModes-final.html/.xls>:

Table 1:   This table lists vendor modes for Draeger, Getinge and GE, along with mappings to the ISO 19223 mode string and IEEE 11073 REFID.  This table will be included in IEEE P11073-10101b and can be extended.

Selectable Adjuncts that are permanently associated with the VendorMode are pre-coordinated into the ISOMode string and the IEEE 11073 REFID.  All Selectable Adjuncts, both ‘inherent’ to the mode and those that are conveyed as Boolean flags are listed in the SelAdjuncts column.

The { TC, CC, LC, NIV, SIGH, TRGC, noFGFC } columns provide a Boolean flag bit view of the Selectable Adjuncts for each VendorMode that are conveyed by ISOMode (indicated by ⦿) and SelAdjuncts (indicated by ●).

The Notes and NoteDetails columns list the notes that are associated with each mode.  The Notes reference numbers are assigned independently of vendor.  [For traceability, the original vendor note numbers are listed in the vNote column.]

Column	Description/Notes
Vendor	Vendor [and optional Model suffix, e.g. GE-R860]
VendorMode	Vendor mode
VendorModeShortDescription	Vendor mode short description

ISOMode	ISO 19223 string, including Selectable Adjuncts and consolidated Note numbers associated with the mode
REFID	IEEE 11073 REFID  (strictly derived from ISO 19223 string)
Disc	Discriminator Group = ‘1’
PART	Partition = ‘7’
CODE10	CODE10
CF_CODE10	32-bit context-free code = (PART * 216) + CODE10
SelAdjuncts	(0..*) Selectable Adjuncts conveyed as Boolean flags
TC	Tube compensation
CC	Compliance compensation
LC	Leakage compensation
NIV	Non Invasive Ventilation
SIGH	SIGH mode
TRGC	Trigger compensation
noFGFC	The additional delivered flow (or tidal volume) due to fresh gas flow is not compensated (anesthesia)
vNotes	Original Vendor Note reference numbers (will not be published in standard)

Notes	(0..*) Note References  (white-space separated consolidated Note numbers)
NoteDetails	(0..*) Note Details  (⬩ separated strings)

vmg	Vendor Mode Group = ‘1’ for initial set of Draeger, Getinge and GE modes  (essential)
gp	10101b Group = ‘6’  (for internal bookkeeping only)

 

Table 2:   This table lists the ISOMode and equivalent IEEE 11073 REFID and numeric codes  and the consolidated Note information associate with the mode.  This table will be included as normative content in IEEE P11073-10101b and can be extended.

Column	Description/Notes
ISOMode	ISO 19223 string, including Selectable Adjuncts and consolidated Note numbers associated with the mode
REFID	IEEE 11073 REFID
Disc	Discriminator Group = ‘1’
PART	Partition = ‘7’
CODE10	CODE10
CF_CODE10	32-bit context-free code = (PART * 216) + CODE10

Notes	(0..*) Note References  (white-space separated consolidated Note numbers)
NoteDetails	(0..*) Note Details  (⬩ separated strings)

 

Table 3:   This table lists the consolidated Note number and details associated with the Note.  This table will be included as normative content in IEEE P11073-10101b and can be extended.

Column	Description/Notes
Note	Note Reference number (consolidated)
NoteDetails	Note Detail

 

*     *     *

Both HTML file use <br style="mso-data-placement:same-cell;”> to prevent Excel row-splitting when multiple <br> are present in the same table cell for the UOM_MDC, UOM_UCUM and new <PEGjs> column.  Excel row-splitting is now permitted for Enum_Values and Enum_Descriptions due to the increased size of the Enum_Descriptions for several of the terms.  I have also provided the Excel version (created by opening the HTML with Excel) for comparison.

During tomorrow’s RTM tcon I will be happy to review and discuss any questions you have.  Time permitting, we can also explore topics related to how the systematic ISO 19223 string syntax and nomenclature can facilitate identification of the ventilation pattern and inflation types and how this information could inform sophisticated message validation in the future.

The Webex tcon information is provided at the end of this email.

Best regards,

Paul Schluter

gmail:  pssch...@gmail.com
cell:  (414) 702-2026

<<AllTogetherGroup6.x4a.2021-08-27T14.isoVentMode-final.html>>  new terms (and potential _SETTINGs)

<<AllTogetherGroup6.x4a.2021-08-27T14.isoVentMode-final.xls>>  new terms (and potential _SETTINGs)

<<ISO-Filter.2e.x3n.2021-08-27T10.isoVentModes-final.html>>  Vendor modes and mappings to ISO 19223 and IEEE 11073 REFIDs and numeric codes

<<ISO-Filter.2e.x3n.2021-08-27T10.isoVentModes-final.xls>>  Vendor modes and mappings to ISO 19223 and IEEE 11073 REFIDs and numeric codes

<<VentModeISO.5g.2021-08-28T17.docx>>  write-up describing ISO 19223 string to IEEE 11073 REFID mapping and current PEGjs validator (content after page 7 is archival)

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, September 15th, and next Wednesday, September 22nd, are cancelled.

I don’t have any new material to discuss for today’s meeting.  Next week, the IEEE EMB 11073 PoCD WG and HL7 Devices (DEV) WG virtual meetings will be held on Tuesday through Friday, September 21 - 24:

Monday 9/20:  HL7 Plenary (no IEEE or DEV meetings)

Tuesday 9/21:  IEEE 11073 PoCD WG  (IEEE 11073 Nomenclature Update starts at 10:45 AM EDT, after the break)

Wednesday 9/22:  HL7 Devices (DEV) WG

Thursday 9/23:  HL7 Devices (DEV) WG and HL7 Mobile Health

Friday 9/24:  Devices on FHIR and Gemini SDC/SDPi Work Session

When we resume our RTM calls on Wednesday, September 29th at 11:00 AM CDT and will be using Zoom which now replaces Webex for most IHE-sponsored teleconferences.  Please update your calendars using the information below if you have not done so already.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

IHE International Coordinator is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting

https://himss.zoom.us/j/92241767931?pwd=TEtqSUVMakExdHhpRUNZVnlXSWxrQT09

Meeting ID: 922 4176 7931

Passcode: 155898

One tap mobile

+16699006833,,92241767931# US (San Jose)

+13462487799,,92241767931# US (Houston)

Dial by your location

        +1 669 900 6833 US (San Jose)

        +1 346 248 7799 US (Houston)

        +1 253 215 8782 US (Tacoma)

        +1 301 715 8592 US (Washington DC)

        +1 312 626 6799 US (Chicago)

        +1 929 205 6099 US (New York)

        833 548 0282 US Toll-free

        877 853 5257 US Toll-free

        888 475 4499 US Toll-free

        833 548 0276 US Toll-free

Meeting ID: 922 4176 7931

Find your local number: https://himss.zoom.us/u/azAA1GxKz

[Paul Schluter]

Greetings!

I am very pleased to announce that the entire set of IEEE P11073-10101b Group4, Group5, Group6 and Group7 terms are now available as irrevocably assigned “provisional” numeric codes.  I would like to thank Michael Faughn who has confirmed that there are no REFID and numeric code conflicts with existing terms or any other terms within this set.  Michael also plans to make the terms available on RTMMSv2 at a later date, possibly by the end of this month, but for now the set of files attached to this email should suffice.  The zip file has been posted on the IEEE-SA iMeet Central site at https://ieee-sa.imeetcentral.com/11073-nomenclature/ .

The four IEEE P11073-10101b term Groups are summarized below:

Group4 and Group5:  Getinge ventilation and anesthesia terms

Group6:  ISO 19223 and IEEE 11073 ventilation modes and related control variables

Group7:  IEEE P11073-10701 SDC terms and miscellaneous units-of-measure

A detailed summary is provided in the README file.  [The companion Group1, Group2 and Group3 terms were sent out in an RTM email on January 22, 2021 at 10:18 CST.]

I would like to thank everyone who has contributed to this effort, including the IHE PCD/DEV domain, the IEEE 11703 and ISO 19223 communities, NIST and Prometheus Computing, and especially representatives from Getinge, Draeger and GE Healthcare who helped make this a reality.  Without your help and guidance, this effort would have been far more difficult!

These topics (and others) will be discussed during next week’s IEEE 11073 General Committee and HL7 Devices (DEV) meetings next week, with the nomenclature discussion currently scheduled to start at 10:45 AM EDT on Tuesday, September 21st.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<NewProvisional.10101b.Group4.Group5.Group6.Group7.2021-09-15.files.zip>>

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, September 29th, is cancelled.  I have a conflict tomorrow.

We will reconvene on Wednesday, October 6 at 11:00 AM CDT.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings,

Please join our RTM tcon today, Wednesday, October 6th at 11:00 AM CDT.

I plan to review the highlights of the IEEE 11073 nomenclature presentation that I gave on September 21, for those of you who were unable to attend the IEEE EMB 11073 PoCD WG and HL7 Devices (DEV) WG virtual meetings that week.  A copy of the presentation is attached.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<IEEE_NomenclatureStatus.2021-09-21.Virtual.2021-09-21T09.final.pptx>>

<<IEEE_NomenclatureStatus.2021-09-21.Virtual.2021-09-21T09.final.pdf>>

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, October 13th, and next Wednesday, October 20th, are cancelled.

I don’t have a sufficient amount of new material for today, and other topics are being discussed by email.  I plan to discuss some of the newer topics at next week’s face-to-face meeting.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

The IHE PCD DEV Domain will be conducting its first face-to-face meeting at BD Headquarters in San Diego (aka ‘AFC’) next week, starting with the Pump WG meeting on Tuesday, October 19 followed by the broader IHE DEV PC, TC and other meetings on Wednesday and Thursday.  You can also participate by using Zoom.

The meeting agenda and Zoom information are available at: https://wiki.ihe.net/index.php/DEV_Domain_F2F_Oct_2021_Zoom#Location_.26_General_Schedule.

 

Best regards, and I look forward to seeing many of you in person next week!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, October 27th, is cancelled.

Our 70 year old driveway is being replaced today and I would like to be available if any last minute issues arise.

We will reconvene next Wednesday, November 3rd.

I would also like to thank Becton Dickinson for hosting our first face-to-face meeting since two years ago and to Lisa Diggett for making the arrangements.  I would also like to thank Kurt Elliason and Tom Kowalczyk for chairing most of our discussions and to Sarah Bell who worked on the meeting logistics.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, November 3rd, is cancelled.

I currently do not have any items of general interest to discuss, but have been working with individuals and individual working groups on various topics.  And needless to say, work continues on preparing the ballot draft of IEEE P11073-10101b.

We will reconvene next Wednesday, November 10th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, November 10th, is cancelled.

I currently do not have any items of general interest to discuss, but have been working with individuals and individual working groups on various topics.  And needless to say, work continues on preparing the ballot draft of IEEE P11073-10101b.

We will reconvene next Wednesday, November 17th.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, November 17th, is cancelled.

I currently do not have any items of general interest to discuss, but have been working with individuals and individual working groups on various topics.  And needless to say, work continues on preparing the ballot draft of IEEE P11073-10101b.

We might reconvene next Wednesday, November 24th.

[Paul Schluter]

Greetings!

The RTM tcon for Wednesday, November 24th, is cancelled, due to the US Thanksgiving Holiday.

Best regards, and have a Happy Thanksgiving Day!

[Paul Schluter]

Greetings!

The RTM tcon for Wednesday, December 1st, is cancelled, 

I currently do not have any items of general interest to discuss, but have been working with individuals and individual working groups on various topics.  And needless to say, work continues on preparing the ballot draft of IEEE P11073-10101b.

We might reconvene next Wednesday, December 8th.

[Paul Schluter]

Greetings!

The RTM tcon for Wednesday, December 8th, is cancelled, 

I currently do not have any items of general interest to discuss, but have been working with individuals and individual working groups on various topics.  And needless to say, work continues on preparing the ballot draft of IEEE P11073-10101b.

We might reconvene next Wednesday, December 15th.

[Paul Schluter]

Seasons Greetings!

The RTM tcons for Wednesday, December 15th, December 22nd and December 29th are cancelled.

I currently do not have any items of general interest to discuss tomorrow, but will continue to work with individuals and working groups on various topics.  And needless to say, work continues on preparing the ballot draft of IEEE P11073-10101b.  The meetings on December 22nd and December 29th are cancelled due to the Holidays, but if you have any pressing issues, please feel free to send me an email.

We will reconvene on Wednesday, January 5th, and I will send out a reminder prior to the meeting.

Until we meet again, Best Wishes for the Holiday Season!

[Paul Schluter]

Greetings, and I trust that you all had a wonderful and safe Holiday Season!

Please join our RTM tcon today, Wednesday, January 5, 2022, at 11:00 AM CST.  The Zoom meeting information is provided below.

I will provide a short status update regarding the IEEE P11073-10101b draft nomenclature standard.  My current focus has been drafting the Systematic Names for events and alerts.  For today’s meeting, I plan to provide an overview of that effort and how the Systematic Names and other event and alert information (e.g. the devices and subsystems and other functionality that can generate them) can facilitate their deployment.

Your feedback will help guide the final stages of this effort, especially regarding how receiving systems can usefully deploy what has now become a very comprehensive set of event and alert identifiers, especially for acute care devices such as physiologic monitoring, ventilators, anesthesia and other sophisticated devices and applications.

I also plan to continue to work with individuals and working groups on various topics as we complete the initial draft of IEEE P11073-10101b for IEEE-SA Mandatory Editorial Coordination (MEC) and start the balloting process.

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, January 12, and next Wednesday, January 19, are cancelled.

We covered a fair amount of territory last week regarding Systematic Names for events and alerts, summarized later in this email.  This will also be discussed during the IEEE 11073 PoCD WG meeting on January 18th starting at 8:00 AM CST, and nomenclature discussion starting at 11:00 AM CST.  As a consequence, the RTM meetings for this week and next are cancelled.

Regarding events and alerts, IEEE P11073-10101b defines over 750 new MDC_EVT identifiers, and together with  500+ previously defined MDC_EVT identifiers, we now have a total of 1250 MDC_EVT event and alert identifiers that can support the majority of acute care PoCD devices in applications and systems using IHE PCD DEC and ACM.  This number will only increase as we add other systems and devices in the future, such as nurse call, beds, etc.

Constructing Systematic Names for this set of terms can be challenging.  First, there are a large number of events and alerts, reflecting vendor variation in design and design philosophy.  Second, certain use-cases and applications may require finer semantic granularity for direct communication between two PoCD devices and less granularity for other applications.  Third, the Systematic Name provides two locations for describing the alert <source>, as well as the mandatory <src> identifier of the <src-evt> pair.  Ensuring that these are all consistent required additional work.

To facilitate the creation of more consistent Systematic Names for 10101b event and alert identifiers, natural language order was imposed wherever possible on the comma-separated fields within the second vertical-bar component of the SysName:

“Subject (source) ,…, Condition/State/Action ,…, {optional qualifiers} ,…, {optional recommendations}

For example:

“The blower temperature is excessively high; checking required”

would have the following Systematic Name:

ErrorEvent | Blower, temperature, excessively high, CheckingRequired | FunctionalDisturbance | Device, Ventilator

The bold font highlighting of the comma-separated Condition/State/Action field is triggered by the presence of certain key words and phrases plus a small number of additional rules.  Comma-separated fields to the left of the Condition/State/Action field are detailed source identifiers and are compared with the fourth component “Device, Ventilator” as well as the proposed <source> identifiers expressed as REFIDs and numeric codes conveyed by the <src-evt> source-event identifier pairs.

I would like to thank Javier Espina Perez, Per Johansson, John Garguilo, Craig Reister and Steven Nichols for their participation and contributions to last week’s meeting and look forward to seeing everyone at next week’s IEEE 11073 PoCD meeting on Tuesday.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, January 26th, 2022, at 11:00 AM CST.  I plan to provide a recap of the IEEE 11073 nomenclature discussion at the IEEE PoCD and HL7 DEV meetings last week, primarily for those of you who were unable to attend or would like to delve more deeply into specific topics.

I have attached the slides <IEEE_NomenclatureStatus.2022-01-25T10.updated-for-IHE-PCD-RTM.pptx/.pdf>.  The slides have been updated to reflect the decision to defer inclusion of new Dialysis Rx Order terms into 10101b until after they have been fully reviewed by clinicians and new vendors who have recently joined this effort (this will not delay the 10101b Group3 “provisional” dialysis observations, events and alerts).  I have also added an additional slide regarding Systematic Name conventions for numeric and other observations, as additional background material if needed.

I look forward to your participation tomorrow.  The Zoom meeting information is provided at the end of this email.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<IEEE_NomenclatureStatus.2022-01-25T10.updated-for-IHE-PCD-RTM.pptx>>

<<IEEE_NomenclatureStatus.2022-01-25T10.updated-for-IHE-PCD-RTM.pdf>>

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, February 2, 2022, is cancelled.

I do not have a sufficient amount of new material for today, and other topics are currently being discussed by email.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I would like to thank Jan-Alrik Philipsen, Michael Faughn, John Garguilo, Norbert Meier, Norman Jones, John Rhoads, Charles Parisot and Kurt Elliason for their participation and contributions to last week’s meeting.  After we reviewed the IEEE Nomenclature Status material from the IEEE PoCD and HL7 DEV meetings from the previous week, we discussed additional testing capabilities that would be desirable to add to our current test tools, based on recent experience at various interoperability test events.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, February 9, 2022, is cancelled.

Kurt Elliason and the IHE PCD Infusion Pump WG have recently added new terms and updated their containment model and I have proposed Systematic Names for the new pump terms.  The updated terms and containment model were sent out to the Pump WG yesterday and will likely be the primary discussion topic at the upcoming Pump WG meeting next Monday, February 14th, at 11:00 AM Central Time (US).  As a consequence, we will not have our usual RTM meeting today.

If you are interested in reviewing the new pump terms and/or joining the Pump WG meeting next Monday, I would be happy to send you the material and meeting invitation.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, February 16, 2022, is cancelled.

Kurt Elliason and the IHE PCD Infusion Pump WG have recently added new terms and updated their containment model and IEEE 11073 Systematic Names were proposed for the new pump terms.

The updated terms were discussed on last Monday (2/14) and we concluded that several terms required further review and clarification.  They will be discussed by email and at the next Pump WG meeting on 2/28.

There was a general consensus that the _DEV substring be removed from the  nine 10101b Group2 “provisional” in Partition 2 that start with MDC_DEV_PUMP.  The numeric codes and definitions will not be changed.  This will allow us to maintain the long-held and very useful convention that only MDC_DEV device identifiers in Partition 1 start with MDC_DEV.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, February 23, 2022, is cancelled.

Our discussion regarding several infusion pump terms continues and we hope to come to a final consensus at the IHE PCD Infusion Pump WG meeting on Monday, February 28, at 11:00 AM CST.

I would appreciate receiving any proposed changes prior to next Monday’s meeting so we can quickly conclude our review and assign final “provisional” numeric codes for the 13+ remaining new terms.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 2, 2022, is cancelled.

We had a very successful review of the new infusion pump terms two days ago (2/28) and have updated the tabular pump containment tree that contains the terms along with their co-constraints and containment context.

The discussion notes for the pump terms, updated Excel file and “distilled” tabular containment tree will be sent out to the Pump WG later today.  If no other issues are identified, the 15+ new terms will be assigned final “provisional” numeric codes after Monday noon next week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 9, 2022, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I did not receive any additional comments regarding the new infusion pump terms, proposed Systematic Names and tabular pump containment tree that was sent out on last Wednesday, so it looks like we’re good to go regarding the assignment of “provisional” numeric codes for the 15+ new pump terms.

The proposed Systematic Names for Dialysis (10101b Group3) and Getinge Ventilator and Anesthesia (10101b Group4 and Group5) are out for final review and hopefully those efforts will be completed shortly.

I am currently preparing final versions of the term tables for IEEE P11073-10101b, starting with MDC_EVTs in Partition 3.  The MDC_EVT terms related to Alarm Inactivation State (AIS) will be placed in a separate subtable and will include all the “practical” AIS discriminator expansions based on existing vendor implementations (for a total of 34 base AIS terms and 65 AIS expansion terms).

I plan to return to the final few remaining terms and topics in 10101b ‘GroupZ’ in the next week or so and plan to contact the individuals who submitted them if I have any questions.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

On Mar 2, 2022, at 8:49 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon for today, Wednesday, March 2, 2022, is cancelled.

We had a very successful review of the new infusion pump terms two days ago (2/28) and have updated the tabular pump containment tree that contains the terms along with their co-constraints and containment context.

The discussion notes for the pump terms, updated Excel file and “distilled” tabular containment tree will be sent out to the Pump WG later today.  If no other issues are identified, the 15+ new terms will be assigned final “provisional” numeric codes after Monday noon next week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<snip snip>

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 16, 2022, is cancelled.  Practically all of the IHE PCD meetings have been cancelled this week since many are attending HIMSS 2022.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I did not receive any additional comments regarding the new infusion pump terms, proposed Systematic Names and tabular pump containment tree that was sent out two weeks ago, so it looks like we’re good to go regarding the assignment of “provisional” numeric codes for the 15+ new pump terms.  I also received additional guidance from Jeff Rinda regarding the correct cardinality for certain data items and additional information about the RXG segment that enables me to also include RXG-5 and RXG-15/16 fields in the containment tree for the PCD-03 transaction.  Thanks, Jeff!

The proposed Systematic Names for Dialysis (10101b Group3) and Getinge Ventilator and Anesthesia (10101b Group4 and Group5) are still out for final review and phone calls have been scheduled for this week to address any remaining questions.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 23rd, 2022, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I am very happy to say that the Systematic Names for Getinge Ventilator and Anesthesia (10101b Group4 and Group5) are now finalized and that the proposed Systematic Names for Dialysis (10101b Group3) are currently out for final review this week.

I am currently working on the best way presenting the 813 “new” (re-including all 65 _AIS expansions used by commercial systems) 10101b MDC_EVT and usefully grouping them while only listing each event or alert exactly once.  I plan to discuss this and related 10101b topics at next week’s RTM call on March 30th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, March 30th, 2022, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I am very happy to say that the REFIDs, Systematic Names, Descriptions have been largely finalized for the 10101b Group2 and Group8 infusion pump terms (except for the possible addition of several finer-grained enumerated values being considered by one vendor).  Pre-provisional numeric codes have been assigned for the new Group8 pump terms and were submitted to Michael Faughn for review and acceptance as “provisional” terms in RTMMSv2.

I am currently consolidating all of the IEEE P11073-10101b terms by partition number and then by device, similar to how the tables in the base IEEE 11073-10101 nomenclature standard are arranged.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, April 6th, at 11:00 AM CDT.

I will provide a walk through our recent work with the IHE PCD Pump WG for the past month regarding the REFIDs, Systematic Names and Descriptions that have been finalized for the 10101b Group2 and Group8 infusion pump terms.  Provisional numeric codes have been assigned for the new Group8 pump terms and Michael Faughn has verified that no code conflicts exist with previously defined terms.

The pump terms were defined in the context of two containment trees, one for the PCD-10 and -01 transactions and the second for the PCD-03 transaction.  Similar to dialysis, the containment tree serves as the overall model for capturing all the nomenclature and co-constraints related to a particular device or class of device, spanning all partitions.  In addition to traditional methods for capturing new IEEE 11073-10101 nomenclature as tables, the containment model provides the added benefit of capturing the device in its entirety and in a manner that can be used to drive rigorous message content modeling, including the ability to validate actual messages (in this work, IHE DEV/PCD DEC conformant HL7 V2 messages).

I sent the updated pump terms to the Pump WG earlier today.  I would like to especially thank Kurt Elliason, Brian Witkowski, Jeff Rinda and everyone in the Pump WG for getting this project to completion and ready for inclusion in IEEE P11073-10101b.  [If you are not a member of the Pump WG and would like a copy of the email I sent earlier today, please let me know!]

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Mar 30, 2022, at 8:46 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon for today, Wednesday, March 30th, 2022, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I am very happy to say that the REFIDs, Systematic Names, Descriptions have been largely finalized for the 10101b Group2 and Group8 infusion pump terms (except for the possible addition of several finer-grained enumerated values being considered by one vendor).  Pre-provisional numeric codes have been assigned for the new Group8 pump terms and were submitted to Michael Faughn for review and acceptance as “provisional” terms in RTMMSv2.

I am currently consolidating all of the IEEE P11073-10101b terms by partition number and then by device, similar to how the tables in the base IEEE 11073-10101 nomenclature standard are arranged.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

The IHE International Coordinator is inviting you to a scheduled Zoom meeting.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, April 13th, 2022, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

We had an informative discussion regarding the new infusion pump terms during last week’s call that also a covered the overall containment model and co-constraints that allow us to capture the device in its entirety and in a manner that can drive rigorous message content modeling and validate messages (in this work, IHE DEV/PCD DEC conformant HL7 V2 messages).  We plan to follow up on these topics at the upcoming IHE PCD F2F meeting in San Diego at the end of this month.

I would like to thank Björn Anderson, Steven Dain, Eldon Metz, John Garguilo and Michael Faughn for attending and contributing to our discussion.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, April 20th, at 11:00 AM CDT.    [The RTM tcon next Wednesday, April 27th, is cancelled due to IHE PCD F2F next week.]

I would like to solicit your input regarding the inclusion of the following information in IEEE P11073-10101b:

1.  Units of measure, both UOM_MDC and UOM_UCUM, as additional columns in the main definitions in Annex A.

Individual units-of-measure can be listed with each term-row that requires them.  Both UOM_MDC and UOM_UCUM will be listed in a side-by-side manner that defines an unambiguous mapping between the two.

Named _UOM_GROUP identifiers can be also be specified that reference _UOM_GROUP identifiers in a compact summary list of all UOM_MDC and UOM_UCUM known to be used in any shipping device, product or system.

I have attached an example of an Annex A table with the additional UOM_MDC and UOM_UCUM information and the current compact summary listing of all the units.

2.  Enumeration _ENUM_GROUPS, Enum_Values and Enum_Descriptions

This information would be specified in a separate Annex.  Although many of the enumerated values are expressed using a single token, others may prefer to use OID values with numeric codes.  These can be captured together in a single normative (but extendable) mapping table dedicated to that purpose, with the following columns:

_ENUM_GROUP membership

  ReferenceID and Part::Code  (if an OID value has been defined)

  Token(s) and optionally ASN.1 flag-bit(s)

  Enum_Description  (applies to all item in the same row)

The _ENUM_GROUPS will use identifiers (e.g. pumps) that have already been defined.  We can also use _MDC_my_refid as the enumeration group identifier for specific term-row having the ReferenceID MDC_my_refid.  The MDC_my_refid will appear in the Annex A Description/Definition and will be trivial to extract from the Definition (since there is no room for this otherwise).  [For export/upload to RTMMSv2, the _ENUM_GROUPS, Enum_Values and Enum_Descriptions in additional columns, as before.]

Of course, we will continue to capture the unit-of-measure and enumerated values in RTMMSv2, as we have done in the past as well as with the original NIST RTMMS.  Using RTMMSv2 is the ideal way to capture and deploy this information (on a database) especially since we expect to continue to extend the enumerated values (and to a lesser extent units) over time.

I look forward to our discussion tomorrow!

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<Example.1a.2022-04-19T15.docx>>   Example Annex A Table with UOM_MDC and UOM_UCUM

<<CheckMDCUnits.4m.x2j.2022-04-09T12.show_X_aliases.html>>  Compact summary list of UOM_MDC and UOM_UCUM units and _UOM_GROUPS

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, May 4th, at 11:00 AM CDT.

I am following up on our discussion from two weeks ago where we talked about adding units-of-measure and enumerated values with descriptions to IEEE P11073-10101b.  I believe the proposal was found acceptable to everyone, with the proviso that we carefully consider any issues related to managing future additions and extensions.  [It is very likely that the additions and extensions will be made first to RTMMSv2, and later captured in later amendments and revisions to IEEE 11073-10101*.]

I have attached a copy of the Excel spreadsheet <AllTogetherNow.x2n.2022-05-03T10.EnumGroupRefs-mso+no-mso.xls> that lists all the 10101b SCADA terms as a concrete example (not surprisingly, this can be copied into the MS-Word draft document with excellent fidelity).  A brief explanation of the worksheets is provided below, and I plan to walk through this material during the RTM tcon tomorrow and even more quickly next Tuesday at the IEEE 11073 PoCD WG meeting, where I will seek overall buy-in and approval by the group.

AllTogetherNow.x2n.2022-05-03T10 …

This lists all the 10101b Part=2 SCADA terms as either (a) subtables that are appended to existing tables in 10101-2019 or (b) as new tables.  The table format is identical to previous IEEE 11073-10101* standards except for the addition of UOM_MDC and UOM_UCUM units-of-measure.  [A compact summary list of UOM_MDC and UOM_UCUM units and _UOM_GROUPS will also be included as a new Annex, based on the table <CheckMDCUnits.4m.x2j.2022-04-09T12.show_X_aliases.html> that I sent to you two weeks ago.  This table will not replace the customary main table listing the new units-of-measure for 10101b.]  The additional UOM_MDC and UOM_UCUM information will fit in the IEEE-SA “large table” format using 8 pt Arial Narrow font, permitted by both the IEEE-SA and ISO.

Annex A terms that have an enumerated value set specify the _ENUM_GROUPS with the text “EnumGroup = _MDC_HDIALY_MACH_MODE_OF_OPERATION” in the Description/Definition.  The _ENUM_GROUP identifier must be globally unique across the entire standard.  Historical _ENUM_GROUPS identifiers are used wherever possible; if one has not been defined, then the REFID for the parent term is used, prefaced by an underscore.

TOC

This is the table of contents from 10101-2019, and this was used to obtain the complete table titles that will be required for the 10101b amendment.

Table C.4.2

This is a listing of the { Reference ID, Disc, Part::Code and CF_CODE10 } that we adopted in 10101a and 10101-2019, derived from the same list of files used to produce Annex A.

Enums-mso and Enums-no-mso

_ENUM_GROUPS   lists the name of the enumeration group

Enum_Values   lists the enumerated tokens that would appear in a text-encoded message, such as HL7 V2.

Enum_Descriptions   list a brief description of the enumerated value

This table will be incorporated in the draft standard with Excel subrows for the Enum_Values, Enum_Descriptions plus additional columns that are added in the future (e.g. ASN.1 mnemonic with a bit-position designator, OID representation using an IEEE 11073 REFID, etc.).  The central idea is that this table represents the mapping between the various on-the-wire representations of the enumerated values, all sharing the common Enum_Description.  We can (and will) define additional requirements and/or guidelines, e.g. all Enum_Values are scoped to the containing parent _ENUM_GROUP identifier, whereas we may strive for globally unique ASN.1 identifiers, and shall have globally unique OID-type identifiers within their defining vocabulary, etc.).

I would like to thank everyone who has participated and contributed to discussions regarding these additions over the past two weeks, including Björn Anderson, Jan-Alrik Philipsen, Monroe Pattillo, Steven Dain, Eldon Metz, Marufur Rahman, Tom Kowalczyk, John Garguilo and especially Michael Faughn.

*     *     *

The RTM tcon that will normally be scheduled for next Wednesday, May 11th, will be cancelled due to upcoming IEEE 11073 PoCD and HL7 DEV SIG Working Group meetings to be held (virtually) next week.  I plan to provide a brief update regarding the status of IEEE P11073-10101b on Tuesday, May 10th, from 11:30 AM to 12:00 Noon US EDT (based on the current draft agenda) and the primary topic will be the addition of the units-of-measure and enumerated values to the draft IEEE P11073-10101b standard.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026


<<AllTogetherNow.x2n.2022-05-03T10.EnumGroupRefs-mso+no-mso.xls>>

[Faughn, Michael R. (Fed)]

I think the question we really need to ask here is if the mappings between MDC and UCUM hold true for every instance where a metric identifies unit co-constraints.  The answer is almost always “yes” but can be “no”.  There are instances where the mappings are scoped just to the unit in question.  Paul and I had this discussion some months ago and it actually led me to extend the model behind RTMMS to accommodate just such a situation.  The mapping that really triggered this was the metric term MDC_SAT_O2_REGIONAL_DELTA_BASELINE_RATIO 2::19640 MMM(0) which was listed with the MDC units MDC_DIM_PERCENT and the UCUM units {Relative}%.  Not every usage of MDC_DIM_PERCENT is a relative percent so the mapping could not be universal and had to be scoped just to that particular metric term.  FWIW, I argued that a new MDC term should be created for relative percent.  “Percent” and “relative percent” are not synonymous concepts.

 

We didn’t really address the question of whether or not this was a bidirectional mapping between UCUM and MDC units either. When I designed RTMMSv2, there was no direct mapping between metric terms and UCUM units.  It was assumed (by me) that mappings between MDC units and UCUM units were universal.  As such, all UCUM units associated with metric terms were derived from the association between the metric term and it’s MDC unit co-constraints.  So, I wasn’t (and really still am not) concerned with a bidirectional mapping.  Is there a use case for mapping from UCUM Units back to MDC Units??

 

Just running some rough scripts on RTMMSv2 here.  This is fairly raw and you’ll notice that there are synonymous UCUM Units that get duplicated and also MDC units that are synonymous as well.  You’ll have to parse through those. 

 

Mapping from MDC Units to UCUM Units…These are probably all OK.  I’m pretty sure all of the UCUM units here are synonyms.  This does not take into account the few instances where there is a scoped mapping as described above.  The mappings that are “per metric scoped” are in the next block of results.

MDC_DIM_PARTS_PER_10_TO_MINUS_9 --> 10*-9, 10^-9

MDC_DIM_PARTS_PER_10_TO_MINUS_12 --> 10*-12, 10^-12

MDC_DIM_X_L_PER_BREATH --> L/{breath}, L, l/{breath}, l

MDC_DIM_MILLI_L_PER_BREATH --> mL/{breath}, mL, ml/{breath}, ml

MDC_DIM_PER_MIN --> {count}/min, 1/min, /min

MDC_DIM_BEAT_PER_MIN --> {beat}/min, {beats}/min, 1/min, /min

MDC_DIM_PULS_PER_MIN --> {pulse}/min, {pulses}/min, 1/min, /min

MDC_DIM_RESP_PER_MIN --> {resp}/min, {breath}/min, {breaths}/min, 1/min, /min

MDC_DIM_X_EQUIV_PER_CM_CUBE --> mol/cm3, eq/cm3

MDC_DIM_CM_H2O_PER_L_PER_SEC --> cm[H2O].s/L, cm[H2O]/(L/s), cm[H2O].s/l, cm[H2O]/(l/s)

MDC_DIM_DYNE_SEC_PER_M_SQ_PER_CM_5 --> dyn.s/cm5/m2, dyn.s.cm-5.m-2

MDC_DIM_X_L_PER_BEAT --> L/{beat}, L, l/{beat}, l

MDC_DIM_BEAT_PER_MIN_PER_X_L --> {beat}/min/L, {beats}/min/L, 1/min/L, /min/L, {beat}/min/l, {beats}/min/l, 1/min/l, /min/l

MDC_DIM_X_LUMEN_PER_M_SQ --> lm/m2, lx

MDC_DIM_MILLI_L_PER_BEAT --> mL/{beat}, mL, ml/{beat}, ml

MDC_DIM_X_ROTATIONS_PER_MIN --> 360.deg/min, 2.[pi].rad/min

MDC_DIM_PER_X_OHM --> 1/Ohm, /Ohm, S

MDC_DIM_DYNE_SEC_M_SQ_PER_CM_5 --> dyn.s.m2/cm5, dyn.s.cm-5.m2

MDC_DIM_X_JOULES_PER_BREATH --> J/{breath}, J

MDC_DIM_MMHG_SEC_PER_ML --> [PRU], mm[Hg].s/mL, mm[Hg].s/ml

MDC_DIM_MMHG_MIN_PER_L --> [wood'U], mm[Hg].min/L, mm[Hg].min/l

MDC_DIM_SQUARE_BREATHS_PER_MIN_PER_L --> {breaths-squared}/min/L, /min/L, {breaths-squared}/min/l, /min/l

MDC_DIM_O2_SAT_PERCENT_SEC --> {sat}.%.s, %.s

MDC_DIM_X_M_PER_VOLT --> mm/mV, m/V

MDC_DIM_X_BAR_SEC_PER_L --> bar.s/L, bar/(L/s), bar.s/l, bar/(l/s)

MDC_DIM_X_L_PER_BEAT_PER_M2 --> L/{beat}/m2, L/m2, l/{beat}/m2, l/m2

MDC_DIM_NANO_VOLT_SEC --> uV.ms, nV.s

MDC_DIM_PER_KILO_OHM --> 1/kOhm, /kOhm, mS

MDC_DIM_MILLI_BAR_SEC_PER_L --> mbar.s/L, mbar/(L/s), mbar.s/l, mbar/(l/s)

MDC_DIM_MILLI_L_PER_BEAT_PER_M2 --> mL/{beat}/m2, mL/m2, ml/{beat}/m2, ml/m2

MDC_DIM_CM_H2O_SEC_PER_BREATH --> cm[H2O].s/{breath}, cm[H2O].s

MDC_DIM_MILLI_BAR_SEC_PER_BREATH --> mbar.s/{breath}, mbar.s

MDC_DIM_HECTO_PASCAL_SEC_PER_L --> hPa.s/L, hPa/(L/s), hPa.s/l, hPa/(l/s)

MDC_DIM_BREATHS_PER_MIN_PER_MILLI_L --> {breaths}/min/mL, {breath}/min/mL, /min/mL, {breaths}/min/ml, {breath}/min/ml, /min/ml

MDC_DIM_BREATHS_PER_MIN_PER_X_L --> {breaths}/min/L, {breath}/min/L, /min/L, {breaths}/min/l, {breath}/min/l, /min/l

MDC_DIM_X_BAR_SEC_PER_BREATH --> bar.s/{breath}, bar.s

MDC_DIM_MICRO_ABSORBANCE --> {microabsorbance}, {unitless}

MDC_DIM_STEP --> {step}, {steps}, {unitless}

MDC_DIM_STEP_PER_MIN --> {step}/min, {steps}/min, 1/min, /min, {unitless}/min

MDC_DIM_TICK --> {tick}, {ticks}

MDC_DIM_X_EVT_PER_HR --> {event}/h, {events}/h, 1/h, /h

MDC_DIM_X_WATT_HR --> W.h, Wh

MDC_DIM_PARTS_PER_10_TO_15 --> 10*-15, 10^-15

MDC_DIM_X_LUMEN --> lm, cd.sr

MDC_DIM_PARTS_PER_10_TO_MINUS_15 --> 10*-15, 10^-15

MDC_DIM_PARTS_PER_10_TO_9 --> 10*-9, 10^-9, [ppb]

MDC_DIM_PARTS_PER_10_TO_12 --> 10*-12, 10^-12, [pptr]

MDC_DIM_PARTS_PER_10_TO_18 --> 10*-18, 10^-18

MDC_DIM_X_ROTATIONS --> 360.deg, 2.[pi].rad

MDC_DIM_INHG --> [in_i'Hg], [in_i’Hg]

MDC_DIM_KILO_WATT_HR --> kW.h, kWh

MDC_DIM_O2_SAT_PERCENT_MIN --> {sat}.%.min, %.min

MDC_DIM_KILO_ROTATIONS --> 360000.deg, 2000.[pi].rad

MDC_DIM_DECI_HZ --> dHz, Hz/10

MDC_DIM_VIAL --> {Vial}, {Vials}

 

All metric terms with scoped mappings.  Ignore the number in square brackets.  The metric mapped to relative percent is highlighted.

Term[7873] Provisional (10101b)  MDC_VOL_FLUID_CONTAINER_START 2::26922 1(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[7890] Provisional (10101b)  MDC_VOL_REMAIN_CONTAINER 2::26923 1(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[7893] Provisional (10101b)  MDC_VOL_FLUID_DELIV_TOTAL 2::26921 1(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[7945] Provisional (10101b)  MDC_VOL_FLUID_DELIV_SEGMENT 2::26920 1(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[40723] Provisional (10101b)  MDC_SAT_O2_REGIONAL_DELTA_BASELINE_RATIO 2::19640 MMM(0)

  Universal mapping: MDC_DIM_PERCENT --> %

  Scoped mapping:    MDC_DIM_PERCENT -- {Relative}%

Term[40946] Provisional (10101b)  MDC_VOL_FLUID_DELIV_PUMP_TOTAL 2::27008 MMM(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[40950] Provisional (10101b)  MDC_VOL_FLUID_DELIV_METHOD_TOTAL 2::27012 MMM(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[40954] Provisional (10101b)  MDC_VOL_FLUID_DELIV_FOR_PERIOD 2::27016 MMM(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

Term[40968] Provisional (10101b)  MDC_VOL_FLUID_DELIV_FOR_DOSE 2::27032 MMM(0)

  Universal mapping: MDC_DIM_MILLI_L --> mL, ml

  Scoped mapping:    MDC_DIM_MILLI_L -- {liquid}mL

 

 

Mappings from UCUM to MDC.  Like I said, I’m not sure we really care about these.  The one in green is definitely not 1:1. Also, do these all look correct? E.g., the one’s in red?

{unknown} --> MDC_DIM_NOS, MDC_DIM_MULT, MDC_DIM_DIV, MDCX_DIM_PSIG

{unitless} --> MDC_DIM_DIMLESS, MDC_DIM_MICRO_ABSORBANCE, MDC_DIM_STEP

1 --> MDC_DIM_DIMLESS, MDC_DIM_RBC, MDC_DIM_BEAT, MDC_DIM_BREATH, MDC_DIM_CELL, MDC_DIM_COUGH, MDC_DIM_SIGH, MDC_DIM_BOOLEAN, MDC_DIM_INR, MDC_DIM_MICRO_ABSORBANCE, MDC_DIM_STEP, MDC_DIM_TICK

dB --> MDC_DIM_DECIBEL, MDC_DIM_DECI_BEL

dB[V] --> MDC_DIM_DECIBEL_X_VOLT, MDC_DIM_DECIBEL_X_V

dB[10.nV] --> MDC_DIM_DECIBEL_10_NANO_VOLT, MDC_DIM_DECIBEL_DECA_NV

[ppth] --> MDC_DIM_PARTS_PER_10_TO_MINUS_3, MDC_DIM_PARTS_PER_THOUSAND, MDC_TST_UNIT, MDC_DIM_PARTS_PER_10_TO_3

[ppm] --> MDC_DIM_PARTS_PER_10_TO_MINUS_6, MDC_DIM_PARTS_PER_MILLION, MDC_DIM_PARTS_PER_10_TO_6

10*-9 --> MDC_DIM_PARTS_PER_10_TO_MINUS_9, MDC_DIM_PARTS_PER_10_TO_9

10^-9 --> MDC_DIM_PARTS_PER_10_TO_MINUS_9, MDC_DIM_PARTS_PER_10_TO_9

10*-12 --> MDC_DIM_PARTS_PER_10_TO_MINUS_12, MDC_DIM_PARTS_PER_10_TO_12

10^-12 --> MDC_DIM_PARTS_PER_10_TO_MINUS_12, MDC_DIM_PARTS_PER_10_TO_12

10*-15 --> MDC_DIM_PARTS_PER_10_TO_15, MDC_DIM_PARTS_PER_10_TO_MINUS_15

10^-15 --> MDC_DIM_PARTS_PER_10_TO_15, MDC_DIM_PARTS_PER_10_TO_MINUS_15

L/m2 --> MDC_DIM_X_L_PER_M_SQ, MDC_DIM_X_L_PER_BEAT_PER_M2

mL/m2 --> MDC_DIM_MILLI_L_PER_M_SQ, MDC_DIM_MILLI_L_PER_BEAT_PER_M2

L --> MDC_DIM_X_L, MDC_DIM_X_L_PER_BREATH, MDC_DIM_X_L_PER_BEAT, MDC_DIM_L

mL --> MDC_DIM_MILLI_L, MDC_DIM_MILLI_L_PER_BREATH, MDC_DIM_MILLI_L_PER_BEAT, DIM_MILLI_L

/min --> MDC_DIM_PER_MIN, MDC_DIM_BEAT_PER_MIN, MDC_DIM_PULS_PER_MIN, MDC_DIM_RESP_PER_MIN, MDC_DIM_STEP_PER_MIN

1/min --> MDC_DIM_PER_MIN, MDC_DIM_BEAT_PER_MIN, MDC_DIM_PULS_PER_MIN, MDC_DIM_RESP_PER_MIN, MDC_DIM_STEP_PER_MIN

/h --> MDC_DIM_PER_HR, MDC_DIM_X_EVT_PER_HR

/min/L --> MDC_DIM_BEAT_PER_MIN_PER_X_L, MDC_DIM_SQUARE_BREATHS_PER_MIN_PER_L, MDC_DIM_BREATHS_PER_MIN_PER_X_L

mL/min/m2 --> MDC_DIM_MILLI_L_PER_MIN_PER_M_SQ, MDC_DIM_MILLI_L_PER_MIN_PER_M2

J --> MDC_DIM_X_JOULES, MDC_DIM_X_JOULES_PER_BREATH

dyn.s/cm5 --> MDC_DIM_DYNE_SEC_PER_CM_5, MDC_DIM_DYNE_SEC_PER_CM5, MDC_DIM_X_DYNE_SEC_PER_CM5

Pa/L --> MDC_DIM_PA_PER_X_L, MDC_DIM_X_PASCAL_PER_L

T --> MDC_DIM_X_TESLA, MDC_Test_UNIT

mol/cm3 --> MDC_DIM_X_MOLE_PER_CM_CUBE, MDC_DIM_X_EQUIV_PER_CM_CUBE

km/h --> MDC_DIM_KILO_M_PER_SEC, MDC_DIM_KILO_M_PER_HR

 {unitless} --> MDC_DIM_TOD, MDC_DIM_DATE

l/m2 --> MDC_DIM_X_L_PER_M_SQ, MDC_DIM_X_L_PER_BEAT_PER_M2

ml/m2 --> MDC_DIM_MILLI_L_PER_M_SQ, MDC_DIM_MILLI_L_PER_BEAT_PER_M2

l --> MDC_DIM_X_L, MDC_DIM_X_L_PER_BREATH, MDC_DIM_X_L_PER_BEAT

ml --> MDC_DIM_MILLI_L, MDC_DIM_MILLI_L_PER_BREATH, MDC_DIM_MILLI_L_PER_BEAT

/min/l --> MDC_DIM_BEAT_PER_MIN_PER_X_L, MDC_DIM_SQUARE_BREATHS_PER_MIN_PER_L, MDC_DIM_BREATHS_PER_MIN_PER_X_L

Pa/l --> MDC_DIM_PA_PER_X_L, MDC_DIM_X_PASCAL_PER_L

 

-Michael

 

 

From: Daniel Rubery <Daniel...@freseniusmedicalcare.com>
Date: Thursday, May 5, 2022 at 5:39 AM
To: ihe-pcd-...@googlegroups.com <ihe-pcd-...@googlegroups.com>, Malcolm Clarke <mclar...@gmail.com>, Paul Schluter <pssch...@gmail.com>, ihe-p...@googlegroups.com <ihe-p...@googlegroups.com>, ihe-p...@googlegroups.com <ihe-p...@googlegroups.com>, IHE DEV Tooling and Testing <ihe-dev...@googlegroups.com>, PCD Technical Committee GG <ihepc...@googlegroups.com>, device...@lists.hl7.org <device...@lists.hl7.org>, Steven Dain <sd...@rogers.com>
Cc: Monroe Pattillo <monroe_...@bellsouth.net>, Mathieu Roullet <mrou...@enovacom.fr>, Stefan Schlichting <stefan.sc...@ornet.org>, Dalibor Pokrajac <Dalibor....@guardrfid.com>, Walsh John L.M.D. <john....@mgh.harvard.edu>, Paul Sherman <paulrsh...@gmail.com>, Garguilo, John J. (Fed) <john.g...@nist.gov>, Crouzier, Nicolas (Assoc) <nicolas....@nist.gov>, Todd Cooper <toddco...@gmail.com>, John Rhoads <johnr...@johnrhoads.net>, Chris Courville <ccou...@epic.com>, Faughn, Michael R. (Fed) <michael...@nist.gov>, Tom.Ko...@bbraun.com <Tom.Ko...@bbraun.com>, Norman Jones <nsjo...@btinternet.com>, Hassing, Kai <kai.h...@philips.com>, Klotz, Tobias <Tobias...@draeger.com>, Ken Fuchs <kenj....@gmail.com>, Gisch, Simon <Simon...@draeger.com>, Abell, Josh <Josh....@draeger.com>, Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>, Tracy Rausch <tr...@docboxinc.com>, Daidi Zhong <daidi...@ieee.org>, Michael J. Kirwan <mki...@dsheet.com>, Lisa Perry <l.p...@ieee.org>, Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>, di...@moberg.com <di...@moberg.com>, Marks, Kenneth E <KEMa...@madisoncollege.edu>, Mike Krajnak <michael...@med.ge.com>, Neal Seidl <Neal....@med.ge.com>, Comunale, Carter <ccom...@bernoullihealth.com>, Szente, Andras <asz...@bernoullihealth.com>, Iglesias, Brian <bigl...@bernoullihealth.com>, Hadi Rahemi <rah...@circulationconcepts.com>, shimp...@marshfieldresearch.org <shimp...@marshfieldresearch.org>, Andrew Norton <andrew...@tiscali.co.uk>, Tietz, Michael <Michae...@draeger.com>, Beier, Manfred <Manfre...@draeger.com>, Per Johansson <per.jo...@getinge.com>, Anders Häggström <anders.h...@getinge.com>, Jeff Rinda <jeffre...@gmail.com>, Nichols, Steven (GE Healthcare) <Steven....@ge.com>, Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>, Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>, Peeters, Wouter <w.pe...@philips.com>, Philipsen, Jan-Alrik <Jan-Alrik...@draeger.com>, Paul Schluter <psch...@center4mi.org>
Subject: Re: [EXTERNAL EMAIL] Re: [ihe-pcd-rtm-vent:1459] Please join our RTM tcon tomorrow, Wednesday, May 4th, at 11:00 AM CDT - additional information to be included in IEEE P11073-10101b (follow-up)

Malcom made the following suggestion a couple of emails back:

 

I am assuming there is a 1:1 mapping, and therefore information on mapping could be included, but it is not clear why a list of UCUM measures should be given for every SCADA term, a mapping table would "save much space" as many terms use common nomenclature.

 

During the meeting yesterday, it was said that there is not always a 1:1 mapping. Can some one provide an example of when there is not a 1:1 mapping between an IEEE UOM and a UCUM UOM?

 

Thanks,

Dan

 

---

From: Steven Dain <sd...@rogers.com>
Sent: Wednesday, May 4, 2022 11:55 AM
To: ihe-pcd-...@googlegroups.com <ihe-pcd-...@googlegroups.com>; Malcolm Clarke <mclar...@gmail.com>; Paul Schluter <pssch...@gmail.com>; ihe-p...@googlegroups.com <ihe-p...@googlegroups.com>; ihe-p...@googlegroups.com <ihe-p...@googlegroups.com>; IHE DEV Tooling and Testing <ihe-dev...@googlegroups.com>; PCD Technical Committee GG <ihepc...@googlegroups.com>; device...@lists.hl7.org <device...@lists.hl7.org>
Cc: Monroe Pattillo <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Stefan Schlichting <stefan.sc...@ornet.org>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <johnr...@johnrhoads.net>; Chris Courville <ccou...@epic.com>; Faughn, Michael R. (Fed) <michael...@nist.gov>; Tom.Ko...@bbraun.com <Tom.Ko...@bbraun.com>; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; Michael J. Kirwan <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com <di...@moberg.com>; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org <shimp...@marshfieldresearch.org>; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Jeff Rinda <jeffre...@gmail.com>; Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>; Peeters, Wouter <w.pe...@philips.com>; Philipsen, Jan-Alrik <Jan-Alrik...@draeger.com>; Daniel Rubery <Daniel...@freseniusmedicalcare.com>; Paul Schluter <psch...@center4mi.org>
Subject: [EXTERNAL EMAIL] Re: [ihe-pcd-rtm-vent:1459] Please join our RTM tcon tomorrow, Wednesday, May 4th, at 11:00 AM CDT - additional information to be included in IEEE P11073-10101b (follow-up)

 

NOT an FMCNA email - External emailHi Paul I think Malcolm suggestion in his last paragraph is reasonable and will save lots of space reducing the cost of standard

Best regards,

Steven

Please excuse the typos

 

On Wed, May 4, 2022 at 11:39, Malcolm Clarke

<mclar...@gmail.com> wrote:

Dear Paul

My take.

In PHD we have always included the list of units that may (should) be used with a metric (normally SCADA), assuming this is informative, ie it is not exhaustive nor mandatory, and could be extended in the future. Likewise we have listed the enumerations that may/should be used in a metric.

However the case for including UCUM in an IEEE 11073 document is not so clear, as we do not encourage its use in place of MDC units in any IEEE based protocol, and indeed for some applications we require and use only 11073 numeric codes.

I am assuming there is a 1:1 mapping, and therefore information on mapping could be included, but it is not clear why a list of UCUM measures should be given for every SCADA term, a mapping table would "save much space" as many terms use common nomenclature.

Regards

Malcolm

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Term Mapping - Ventilator Task Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm-ve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm-vent/BE8B0D97-88CE-4A7A-B648-99B96C629D31%40gmail.com.

 

 

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Term Mapping - Ventilator Task Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm-ve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm-vent/BE8B0D97-88CE-4A7A-B648-99B96C629D31%40gmail.com.

 

 

 

 

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Term Mapping - Ventilator Task Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm-ve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm-vent/BE8B0D97-88CE-4A7A-B648-99B96C629D31%40gmail.com.

 

 

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Term Mapping - Ventilator Task Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm-ve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm-vent/BE8B0D97-88CE-4A7A-B648-99B96C629D31%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Term Mapping - Ventilator Task Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm-ve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm-vent/46440b79-02f7-8b6c-0982-3894f4698e75%40gmail.com.

[Paul Schluter]

Dan, Malcolm and colleagues,

Here’s one example, involving ‘%’, where ‘%’ is often used as a stand-alone symbol and where the precise meaning of percent is inferred by the quantity being measured.  There are numerous other variants of ‘%’ that can be found in the CDC and other guidelines regarding the use of UCUM and UCUM {annotations}.  [The two ‘%’ in blue font would be computationally equivalent since a UCUM {annotation} is unitless, i.e. ‘1’.]  There are other examples as well.

CF_UCODE10	UCODE10	UOM_MDC	Unit_of_Measure	UOM_UCUM	_UOM_GROUPS
262688	544	MDC_DIM_PERCENT	10-2 (percent)	%	_UOM_CONC_GAS
268384	6240	MDC_DIM_VOL_PERCENT	volume percent	%{vol} %	_UOM_CONC_GAS
263392	1248	MDC_DIM_PCT_PCV	percent of packed cell volume	%{pcv} %
274688	12544	MDC_DIM_RELATIVE_PERCENT	relative percent	%{relative} {relative}.% %

Over the years, the capturing both UOM_MDC and UOM_UCUM based on expert vendor and clinician input and review allows us to support cases where a common symbol such as ‘%’ can be used in an unambiguous manner relative to the context provided by the parent observation identifier.  

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On May 5, 2022, at 6:37 AM, Daniel Rubery <Daniel...@freseniusmedicalcare.com> wrote:

Malcom made the following suggestion a couple of emails back:

I am assuming there is a 1:1 mapping, and therefore information on mapping could be included, but it is not clear why a list of UCUM measures should be given for every SCADA term, a mapping table would "save much space" as many terms use common nomenclature.

During the meeting yesterday, it was said that there is not always a 1:1 mapping. Can some one provide an example of when there is not a 1:1 mapping between an IEEE UOM and a UCUM UOM?

Thanks,

Dan

---

From: Steven Dain <sd...@rogers.com>
Sent: Wednesday, May 4, 2022 11:55 AM
To: ihe-pcd-...@googlegroups.com <ihe-pcd-...@googlegroups.com>; Malcolm Clarke <mclar...@gmail.com>; Paul Schluter <pssch...@gmail.com>; ihe-p...@googlegroups.com <ihe-p...@googlegroups.com>; ihe-p...@googlegroups.com<ihe-p...@googlegroups.com>; IHE DEV Tooling and Testing <ihe-dev...@googlegroups.com>; PCD Technical Committee GG <ihepc...@googlegroups.com>; device...@lists.hl7.org <device...@lists.hl7.org>
Cc: Monroe Pattillo <monroe_...@bellsouth.net>; Mathieu Roullet <mrou...@enovacom.fr>; Stefan Schlichting <stefan.sc...@ornet.org>; Dalibor Pokrajac <Dalibor....@guardrfid.com>; Walsh John L.M.D. <john....@mgh.harvard.edu>; Paul Sherman <paulrsh...@gmail.com>; Garguilo, John J. <john.g...@nist.gov>; Crouzier, Nicolas <nicolas....@nist.gov>; Todd Cooper <toddco...@gmail.com>; John Rhoads <johnr...@johnrhoads.net>; Chris Courville <ccou...@epic.com>; Faughn, Michael R. (Fed) <michael...@nist.gov>; Tom.Ko...@bbraun.com <Tom.Ko...@bbraun.com>; Norman Jones <nsjo...@btinternet.com>; Hassing, Kai <kai.h...@philips.com>; Klotz, Tobias <Tobias...@draeger.com>; Ken Fuchs <kenj....@gmail.com>; Gisch, Simon <Simon...@draeger.com>; Abell, Josh <Josh....@draeger.com>; Staudenmaier, Greg (Stod) <Greg.Sta...@va.gov>; Tracy Rausch <tr...@docboxinc.com>; Daidi Zhong <daidi...@ieee.org>; Michael J. Kirwan <mki...@dsheet.com>; Lisa Perry <l.p...@ieee.org>; Sabo, Perry (Carefusion, non-GE) <perry...@carefusion.com>; di...@moberg.com <di...@moberg.com>; Marks, Kenneth E <KEMa...@madisoncollege.edu>; Mike Krajnak <michael...@med.ge.com>; Neal Seidl <Neal....@med.ge.com>; Comunale, Carter <ccom...@bernoullihealth.com>; Szente, Andras <asz...@bernoullihealth.com>; Iglesias, Brian <bigl...@bernoullihealth.com>; Hadi Rahemi <rah...@circulationconcepts.com>; shimp...@marshfieldresearch.org <shimp...@marshfieldresearch.org>; Andrew Norton <andrew...@tiscali.co.uk>; Tietz, Michael <Michae...@draeger.com>; Beier, Manfred <Manfre...@draeger.com>; Per Johansson <per.jo...@getinge.com>; Anders Häggström <anders.h...@getinge.com>; Jeff Rinda <jeffre...@gmail.com>; Nichols, Steven (GE Healthcare) <Steven....@ge.com>; Ramachandran, Karthik R (GE Healthcare) <r.karthikr...@med.ge.com>; Brauer, Kimberly (GE Healthcare) <Kimberl...@ge.com>; Peeters, Wouter <w.pe...@philips.com>; Philipsen, Jan-Alrik <Jan-Alrik...@draeger.com>; Daniel Rubery <Daniel...@freseniusmedicalcare.com>; Paul Schluter <psch...@center4mi.org>

Subject: [EXTERNAL EMAIL] Re: [ihe-pcd-rtm-vent:1459] Please join our RTM tcon tomorrow, Wednesday, May 4th, at 11:00 AM CDT - additional information to be included in IEEE P11073-10101b (follow-up)

 

NOT an FMCNA email - External emailHi Paul I think Malcolm suggestion in his last paragraph is reasonable and will save lots of space reducing the cost of standard

Best regards, 

Steven

Please excuse the typos

On Wed, May 4, 2022 at 11:39, Malcolm Clarke

<mclar...@gmail.com> wrote:

Dear Paul

My take.

In PHD we have always included the list of units that may (should) be used with a metric (normally SCADA), assuming this is informative, ie it is not exhaustive nor mandatory, and could be extended in the future. Likewise we have listed the enumerations that may/should be used in a metric.

However the case for including UCUM in an IEEE 11073 document is not so clear, as we do not encourage its use in place of MDC units in any IEEE based protocol, and indeed for some applications we require and use only 11073 numeric codes.

I am assuming there is a 1:1 mapping, and therefore information on mapping could be included, but it is not clear why a list of UCUM measures should be given for every SCADA term, a mapping table would "save much space" as many terms use common nomenclature.

Regards

Malcolm

-- 
You received this message because you are subscribed to the Google Groups "IHE PCD Rosetta Term Mapping - Ventilator Task Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-pcd-rtm-ve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-pcd-rtm-vent/BE8B0D97-88CE-4A7A-B648-99B96C629D31%40gmail.com.

[Paul Schluter]

Dan, Malcolm, Michael and colleagues,

Although a reversible 1:1 mapping UOM_MDC —> UOM_UCUM —> UOM_MDC is desirable goal, it is not always possible to achieve, but we come very close as I will demonstrate later in this email.

The primary goal was to ensure an accurate mapping from UOM_MDC —> UOM_UCUM since UCUM is the dominant unit-of-measure representation for enterprise medical information transfer, especially FHIR, HL7 V3 and more recently HL7 V2.  DICOM also now largely mandates the use of UCUM as well.  UCUM units are very human readable and the representation is composable and computable and is well-supported by a variety of resources (e.g. validators, supporting data sets, etc.) available from multiple organizations.

So, here’s some additional background:

The <CheckMDCUnits…html> file lists the UOM_UCUM terms with the first (left-most) token having the greatest precision, in some cases achieved by using a unitless UCUM {annotation} — for example, %{vol} and %{pcv} to more closely match MDC_DIM_VOL_PERCENT and MDC_DIM_PCT_PCV, respectively.  However, in the UCUM representation, both %{vol} and %{pcv} are computationally equivalent to ‘%’ and are therefore not a 1:1 mapping from a computational perspective since a receiver could elide the {annotation}s.

This is important to keep in mind when defining the parent observation identifier - it must include one or more REFID atoms to make the distinction (volume percent vs packed cell volume) very clear and/or otherwise provide sufficient context.  For all 10101a, 10101R and 10101b terms, the REFID includes the distinguishing sub-identifiers in almost all cases so that there is no reliance on the UCUM unit-of-measure to further disambiguate the term.  However, since disambiguation either by using sub-identifiers and/or other context is not always possible, capturing the UOM_MDC and UOM_UCUM is necessary.

To support this level of review, the UOM_UCUM tokens are ordered with the greatest specificity (including any {annotation}s) listed first to the lowest level of specificity listed last.  A good example of this is MDC_DIM_BEAT_PER_MIN, with {beat}/min providing the closest match and 1/min or /min being the most general but computationally equivalent UCUM expression.

UOM_MDC:  MDC_DIM_BEAT_PER_MIN   ‘beats per minute’   UOM_UCUM:  {beat}/min {beats}/min 1/min /min   

All UOM_UCUM synonym terms must work with the parent observation identifier, e.g. MDC_ECG_HEART_RATE, both subjectively (by eyeball) as well as computationally. Listing the entire set of UOM_UCUM units-of-measure that are sensible mappings from the UOM_MDC term also serve as a reminder of the semantic and computational range of UOM_UCUM terms that are considered a match with the UOM_MDC unit-of-measure.

The second HTML file <ReversibleUnits.x1a…html> demonstrates that a nearly 1:1 reversible mapping relationship exists when the UOM_UCUM tokens with the greatest level of specificity are used for matching.  The ‘R’ column shows the number of reverse matches, with ‘1’ indicating a 1:1 mapping relationship.  There are two pairs of term-rows (for [ppth] and [ppm]) that share two REFID-synonym identifiers, indicated by R = ‘2’ with light-yellow shading.  There are also two UOM_MDC units, MDC_DIM_TOD and MDC_DIM_DATE that do not have UOM_UCUM mappings, and these are indicated by R = ‘0’ with light-red shading.

So at the finest level of granularity we have a 1:1 reversible mapping when comparing the UOM_MDC REFID and UCUM tokens as strings, but as you move towards the more general UOM_UCUM representations the 1:1 reversible mapping is lost and compels us to list the UOM_MDC and UOM_UCUM units on a per observation identifier basis.  Furthermore, listing the observation identifier and units-of-measure together will facilitate comprehension and review as well as implementation and validation later on.

For the reasons cited above, I recommend that we include the UOM_MDC and UOM_UCUM units and mappings in IEEE P11073-10101b that are (1) supported by existing device and system implementations, (2) are supported by the expert vendor and clinical user and research communities and (3) are correct from a physics, chemistry, biochemistry and other related disciplines.  I believe that we have already achieved this level of correctness and believe we should include the UOM_MDC and UOM_UCUM units directly in Annex A where they will be directly available for review during the IEEE P11073-10101b balloting process.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<CheckMDCUnits.4m.x2j.2022-04-09T12.show_X_aliases.html>>  this is the same file I sent in earlier emails

<<ReversibleUnits.x1a.2022-05-05T14.first-ucum-only.html>>  with evaluation of the number of reverse matches in the ‘R’ column

[Paul Schluter]

Greetings!

I am sending you this email as a follow-up regarding an alternative solution for including enumerated value sets, i.e. { _ENUM_GROUP, Enum_Values and Enum_Descriptions }, in IEEE P11073-10101b.  In a nutshell, we would use individual MS-Word tables for each enumerated value set, similar to how we already represent major enumeration value sets for infusion pumps and ventilation modes in previous standards.

This can eliminate the need for creating numerous _MDC_enum_group_identifiers using the parent observation REFID with a reference (and link) to individual tables in the standard.  This should address the concerns by Michael Faughn, Eldon Metz and others that we were creating an additional vocabulary of group identifiers when all we’re trying to do is extend the number of columns beyond what is shown on an 8-1/2 x 11 landscape “large table” format.

So, the proposal is:

In the Description/Definition we would include text similar to  "See Table A.1.3.4” (which was sufficient as normative text in earlier standards) as the forward reference (with MS-Word link) to the table.  This would not create any additional underscore-prefixed “vocabulary”, just as including the same information in the same conceptual table row in RTMMSv2 does not imply a group identifier other than the term row itself.

Individual enumerated value set tables would contain the following columns (at a minimum) plus addition columns if multiple on-the-wire representations are permitted:

Enum_Values   lists the enumerated tokens that would appear in a text-encoded message, such as HL7 V2.

Enum_Descriptions   list a brief description of the enumerated value

We could also include additional columns for ASN.1-style mnemonic(bit-position or decimal value) and/or OID-type identifiers and other information, including alternative standard identifiers and other information (see IEEE Std 11073-10101-2019 Table A.8.4.6.1—Nomenclature and codes for electrode sites for EEG according to the international 10–20 system as an example).

The MS-Word Table Identifier (e.g. 'Table A.8.4.6.1') for each enumerated value table serves as the target for the one or more references specified the Description/Definitions that reference it, in addition to the hyperlinks supported by MS-Word.  Additionally, the Table Title/Caption will also include the _MDC_enum_group_identifier if one has already been defined.  If the enumerated value set is used by a single observation identifier, then we can include a back reference that includes the REFID of the parent observation.

An example is shown below from dialysis, where the parent observation identifier REFID is enclosed in square brackets:

Table A.x.y.z – Dialysis Mode of Operation [MDC_HDIALY_MACH_MODE_OF_OPERATION]

Enum_Values	Enum_Descriptions
PRETX	Pre-Treatment – Preparing for dialysis but no blood in extracorporeal circuit
TX	Treatment – Blood in the extracorporeal circuit
POSTTX	Post-Treatment – After dialysis but no longer any blood in extracorporeal circuit
DIS	Disinfection or rinse of dialysis fluid path.
IDL	Idle
SVC	Service mode

In general, square brackets (or other consistently applied delimiter pair) should be used to enclose either the parent observation identifier REFID (without the leading underscore) or the _MDC_enum_group_identifier (with leading underscore) so that the linkage between multiple tables can be determined and/or verified relative to the linkage provided by MS-Word.  This also helps preserve the association if the material has been copied to another repository or customer-facing document.

This proposal will eliminate the need for creating numerous _MDC_enum_group_identifiers for the simple case where the enumerations are scoped only to the term-row that defines them.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Malcolm and colleagues,

You can always use the first-listed UOM_UCUM token when exporting data from a PHD gateway since it is a precise and reversible 1:1 match to the original UOM_MDC token.

In the IHE PCD DEC world, gateways are often configured to satisfy customer requests regarding how the unit-of-measure is sent, so the comprehensive summary table lists all the other equivalent mapping to UCUM that are also considered valid in practically all cases.  We need to be able to validate those systems and their messages, too.  For example, customers may prefer the shorter expression, e.g. /min instead of {beats}/min, for brevity or because it matches what is displayed on their patient monitors.

The best way to view this is that the UOM_MDC and UOM_UCUM terms specified in Annex A with each observation identifier are based on the collective experience of all vendors that have participated in the IHE PCD effort for nearly the past two decades.  This represents the core and most widely-used sets of units that have been found to match existing devices, systems and customer expectations.  The ability to specify the units of measure on a term-by-term basis allow us to validate messages that may use alternative but equally valid units-of-measure using the NIST Test Tools and other testing frameworks, all based on open standards.

Every unit-row in the comprehensive summary table is correct from a physics, chemistry or other discipline, allowing us to successfully validate systems that may have been configured to support customer requirements or expectations.

I also agree with Michael regarding his observation that we have not seen any request or use-case for a UOM_UCUM to UOM_MDC mapping at the present time - it has always been in the UOM_MDC to UOM_UCUM direction, given that UCUM is now mandated by practically every enterprise interface that uses FHIR, HL7 V3 and more recently HL7 V2 and DICOM.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

Dear Paul

There are two aspects to this discussion:

1. The physics, convention or definition of a term will also define the single unit that is accepted (or equivalents). It is to be expected that every coding scheme will give that unit with that term. It is hard to conceive otherwise. Why does one scheme define the unit for a term differently? They must be the same.

2. In implementing a generic gateway it is conceivable only to provide rules or a simple mapping table of MDC_unit to UCUM, it is not realistic to include the entire RTMMS with the UCUM code for every term, nor hunt RTMMS for exceptions and code for these. We must attain 1:1 mapping for sanity and for respect (why are these IEEE people always different?).

Regards

Malcolm

[Paul Schluter]

Greetings!

The RTM tcon normally scheduled for this Wednesday, May 11th, is cancelled due to upcoming IEEE 11073 PoCD and HL7 DEV SIG Working Group meetings to be held (virtually) this week.

I plan to provide a brief update regarding the status of IEEE P11073-10101b on Tuesday, May 10th, from 11:30 AM to 12:00 Noon US EDT (based on the current draft agenda) and my primary topic will be the addition of the units-of-measure and enumerated values to the draft IEEE P11073-10101b standard, plus other topics.  The meetings continue to Friday this week.

The draft agenda for the IEEE 11073 PoCD and HL7 DEV SIG Working Group meetings is available at https://confluence.hl7.org/display/HCD/Agenda%3A+2022-May+9+thru+13+-+IEEE+11073+and+HL7+DEVICES+Joint+Working+Group+Meetings%2C+Virtual .

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026The 

[Paul Schluter]

Greetings,

Please join our RTM tcon tomorrow, Wednesday, May 18, at 11:00 AM CDT.  

I will provide a brief status update regarding IEEE P11073-10101b and the final decisions regarding regarding how of units-of-measure and enumerated values will be included in the published standard.  I will also cover several IHE PCD related topics, listed below. 

• IEEE P11073-10101b “provisional” term groups and status
• 10101b:  MDC and UCUM units-of-measure will be included
• 10101b:  Enumerated values with definitions will be included
• PCD DEC:  In-line technical events  (a future PCD CP)
• PCD DEC:  Containment and Content Modeling
• Dialysis:  Prescription Transfer and Treatment ‘Run Sheet'

The meeting minutes were graciously taken by Kosta Makrodimitris (PoCD) and John Garguilo (HL7 DEV) and are posted at https://confluence.hl7.org/pages/viewpage.action?pageId=90341380.  If you do not have access to the HL7 Confluence site, I have attached a copy of my 5/12 presentation that will be used for tomorrow’s discussion.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<IHE_DEV_F2F_IEEE_NomenclatureStatus.1c.2022-05-12T10.ieee+pcd.pdf>>

On May 9, 2022, at 4:24 PM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon normally scheduled for this Wednesday, May 11th, is cancelled due to upcoming IEEE 11073 PoCD and HL7 DEV SIG Working Group meetings to be held (virtually) this week.

I plan to provide a brief update regarding the status of IEEE P11073-10101b on Tuesday, May 10th, from 11:30 AM to 12:00 Noon US EDT (based on the current draft agenda) and my primary topic will be the addition of the units-of-measure and enumerated values to the draft IEEE P11073-10101b standard, plus other topics.  The meetings continue to Friday this week.

The draft agenda for the IEEE 11073 PoCD and HL7 DEV SIG Working Group meetings is available at https://confluence.hl7.org/display/HCD/Agenda%3A+2022-May+9+thru+13+-+IEEE+11073+and+HL7+DEVICES+Joint+Working+Group+Meetings%2C+Virtual .

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for tomorrow, Wednesday, May 25th, is cancelled.  

I do not have any new material to discuss tomorrow, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I would like to thank John Garguilo, Michael Faughn, Eldon Metz and Stephen Dain for attending last week’s meeting where we went over the topics listed in the RTM invitation immediately below.

To everyone in the US, have an enjoyable and meaningful Memorial Day weekend!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, June 1st, at 11:00 AM CDT.  We will discuss the two somewhat esoteric topics below:

1.  NMT (Neuromuscular Transmission) Monitoring - units-of-measures for absolute measurements 

Although the majority of NMT measurements are reported as relative values (e.g. TOF%) rather than as absolute measurements, there are devices and systems that report absolute measurements as well.  The NMT response can be measured using a variety of methods listed below, and my question to any of you (that design or market or interface to) an NMT system are what are the additional units-of-measure that could be reported by commercially available systems that should be listed along with the units-of-measure highlighted with yellow below?

The set of units will be collectively represented by the _UOM_NMT_AMPL unit-of-measure group referenced the twelve NMT “absolute” numeric measurements, including evoked response.  Representing the set of units as a _UOM_GROUP will facilitate adding units later on and/or as new sensing technologies for the NMT evoked response are developed in the future.

Technique	Acronym	UOM_MDC	UOM_UCUM	Notes
Generic or undisclosed method		MDC_DIM_NOS	{unknown}
Electromyography	EMG	MDC_DIM_MILLI_VOLT	mV
Mechanomyography  (force, tension)	MMG	MDC_DIM_G_FORCE	gf	Note: gram-force is now an MDC unit!
Aceceleromyography  (linear, angular or 3D acceleration of thumb)	AMG, 3D AMG	MDC_DIM_CENTI_M_PER_SEC_SQ	cm/s2	Assume conversion of angular to linear acceleration is performed.  Also, assume conversion of [g] G’s to cgs cm/s2.
Kinemyography  (piezo)  (angular velocity and/or displacement of thumb)	KMG
Phonomyography  (lower frequency sounds, condenser or piezo)	PMG
Compressomyography  (Modified NIBP cuff)	CMG

2.  Dialysis - define two query identifiers for QPD-1 Message Query Name (first three fields of the CWE) 

MDC_QRY_HDIALY_RX_QUERY^Dialysis Prescription Query^MDC   (hemodialysis)

MDC_QRY_PDIALY_RX_QUERY^Peritoneal Dialysis Prescription Query^MDC  (peritoneal dialysis)

The EMR system copies this value into the QAK-3 filed in the response.

The QPD-1 MDC_QRY codes play a similar role to the ORB-4 MDC_OBS codes we have defined in the past - they provide a high-level indication of the clinical intent of the QPD-1 query or OBR-4 observation set that can facilitate more precise message modeling and validation as well as facilitate rapid decoding by receivers.

I plan to define the two MDC_QRY_ codes starting at 1::3648, which is 64 codes above 1::3584 used for MDC_OBS Observation sets that can be conveyed by OBR-4.  If you have any other guidance, please let me know.

I look forward towards you participation later today.  If you would like to propose additional units-of-measure for NMT absolute measurements and/or evoked response, please provide a copy of the vendor documentation and/or clinical paper that lists the specific units-of-measure by the end of this week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

Synopsis of how the HL7 Query by Parameter will be used  (from my IEEE 11073 and HL7 Meeting Slides on May 12)

Optional first step:  The IHE Patient Demographics Query (PDQ) transaction is used for retrieving information about the dialysis patient.  The information includes first name, last name, date of birth, gender, and medical record number and is used when requesting prescription information from the EMR. [A total of five patient identification use-cases have been identified. This step is optional if an authoritative patient identifier such as an MRN scanned by the dialysis machine from a wrist band or RFID is available.]

The dialysis machine uses an HL7 Query By Parameter / Segment Pattern Response model.  The dialysis machine sends patient identifying information to the EMR which in turn responds with the 50 to 70+ parameters needed to specify the dialysis treatment for the patient, formatted as a PCD DEC-compliant HL7 V2 message.

HL7 V2.7  CH02C Code Tables   2.C.2.235      0471 - Query Name

Table Metadata

Table	Steward	V3 Harmonization	V3 Equivalent	Where used	Status
0471	InM	TBD	TBD	QPD-1, QAK-3, QID-2	Active

User-defined Table 0471 - Query Name

Value	Description	Comment
	No suggested values defined

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 8th, is cancelled.  

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

I would like to thank Monroe Pattillo, Dan Rubery, Jan-Alrik Philipsen, Michael Faughn, Eldon Metz and Steven Nichols for attending last week’s meeting where we covered the two topics listed in the RTM invitation below.  Everyone was satisfied with the proposals and they have been incorporated into IEEE P11073-10101b.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 15th, is cancelled.  

I do not have any new material to discuss today, and other topics have been discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 22nd, is cancelled.  

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

[Paul Schluter]

Greetings!

The RTM tcons for tomorrow, Wednesday, June 29th, and the following Wednesday, July 6th, are cancelled.  

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

Best regards, and for those of you in the United States, have a safe and enjoyable Fourth of July!

[Paul Schluter]

Greetings!

Please join our RTM tcon today, Wednesday, July 13th, at 11:00 AM CDT.  

We will discuss two options for listing the new MDC_EVT terms in IEEE P11073-10101b, which now total around 819 terms.  These have been grouped together into 132 table subsections to facilitate review and allow readers to focus on the devices and topics they are interested in.  The table sections are especially helpful for complex devices and topics, including ventilators and anesthesia machines; hemodialysis machines; infusion pumps as well as Alarm Inactivation State (AIS); typical measurement errors and other important categories.

The two options are described below:

Option 1:  List all new 10101b MDC_EVT terms grouped together with MDC_EVT terms from ISO/IEEE 11073-10101:2020 (with full Definitions, Systematic Names, etc.)

All new 10101b MDC_EVT terms with be listed together with MDC_EVT terms from ISO/IEEE 11073-10101:2020, with full Definitions, Systematic Names, etc.  A summary REFID, Disc, Part::Code and CF_CODE10 listing will also be provided, similar to what can be found in 10101:2020 Annex C.  An example HTML listing with term grouping is attached.

Option 2:  List only the new 10101b MDC_EVT terms (with full Definitions, Systematic Names, etc.) but also provide a summary REFID and code listing with grouped like-kind terms

The principal rationale for this approach is that the existing 545 MDC_EVT terms from 10101:2020 would not be included for brevity, focusing only only the 819 new terms for 10101b (which, after all, is an amendment).  The summary REFID and code listing would include both with grouping of like-kind terms.

My recommendation is to go with Option 1, since it allows all MDC_EVT terms, both “old” and “new”, to be reviewed together, helping ensure consistency and completeness.  We did this once before with ISO/IEEE 11073-10101a-2015, where all the “old” ventilator and anesthesia terms were combined with a significant number of “new" 10101a terms, allowing reviewers to review the terms together as a complete  whole.  Ensuring that the entire set of 1364 MDC_EVT identifiers is as consistent and comprehensive as possible will facilitate future work (after 10101b has been approved) to combine this comprehensive set with other information (parameters that use the events and the permitted <source> identifiers for each <event> identifier) to be complete and accurate as possible.

Thanks and regards, and I look forward to our discussion later today!

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<<MakeEventList.x1d.2022-07-12T17.html>>  Trimmed list with grouping (gp, s and skvt will not be included in the published standard)

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 20, is cancelled.  

I do not have any new material to discuss today, and other topics are being discussed with individual groups.

Regarding our topic from last week, the consensus by those who attended the call and others by email, we will go with Option 1 (list all new 10101b MDC_EVT terms grouped together with MDC_EVT terms from ISO/IEEE 11073-10101:2020).  I would like to thank Monroe Pattillo, Kurt Elliason, Eldon Metz and Steven Nichols for attending the call last week as well as everyone else who weighed in by email.

Needless to say, work continues on the first ballot draft of IEEE P11073-10101b, which is now over 160+ pages with the Annex A tables for the Partition 1, 2 and 3 terms.

Best regards, and have an enjoyable summer1

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

<MakeEventList.x1d.2022-07-12T17.html>

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, July 27, is cancelled.  

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Needless to say, work continues on the first ballot draft of IEEE P11073-10101b.

Best regards, and have an enjoyable summer!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, August 3rd, and next Wednesday, August 10th, are cancelled.  

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Work continues on the first ballot draft of IEEE P11073-10101b.

I will be vacationing in Door County next week.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, August 17th, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Work continues on the first ballot draft of IEEE P11073-10101b with particular focus on two Annexes (one normative and the other informative) regarding ventilator mode based on ISO 19223.

Best regards, and enjoy your summer!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

PS.  As many of you know, HIMSS will be moving away from Zoom as their teleconference service and will instead be utilizing Microsoft Teams.  We will transition from Zoom to Microsoft Teams for the RTM calls on or around September 7th after we receive the updated teleconference information from Sarah Bell. 

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, August 24th, is cancelled.

I do not have any new material to discuss today, and other topics are being discussed with individual groups.  Work continues on the first ballot draft of IEEE P11073-10101b with practically all major sections now incorporated into the MS-Word document, and final sets of machine-readable pre-ballot-draft tables will be sent to Michael Faughn for incorporation in RTMMSv2.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, August 31st, is cancelled.

I am very happy to say that the first (pre-MEC) draft of IEEE P11073-10101b is nearly ready for a 7 to 14 day preliminary review by the IEEE 11073 PoCD WG, followed by a vote of the PoCD WG to send the draft to 11073 Steering Committee (SC) for approval to initiate the SA ballot.  At that point ballot group formation will commence (and hopefully many of you will be able to participate) and Mandatory Editorial Coordination (MEC) by the IEEE-SA editorial staff will also begin.

I plan to post the first (pre-MEC) pdf draft on the IEEE-SA website later this week or very early next.  I will also host RTM calls on September 7th and/or September 14th to provide a short overview and to answer any questions and possible concerns that you have.  The IEEE 11073 PoCD WG will have an opportunity to formally “vote to proceed with balloting” by e-ballot prior to the IEEE 11073 PoCD WG and GC meetings in Baltimore on September 19th and/or 20th, and hopefully the IEEE 11073 SC will be able to formally vote to proceed if we have a quorum at the Baltimore meeting; otherwise, the SC vote will be via e-ballot as well.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026


PS.  As many of you know, HIMSS will be moving away from Zoom as their teleconference service and will instead be utilizing Microsoft Teams.  We will transition from Zoom to Microsoft Teams for the RTM calls on or around September 7th after we receive the updated teleconference information from Sarah Bell. 

PPS.  The pre-MEC draft IEEE P11073-10101b is currently 282 pages long! 

[Paul Schluter]

Greetings!

 
I am very happy to say that the first pre-MEC draft of IEEE P11073-10101b nomenclature amendment is now available for review by the IEEE 11073 PoCD WG, with the goal of completing the online “vote to proceed with balloting” within the next ten days.  After a successful PoCD WG vote, the IEEE 11073 Steering Committee will conduct a similar vote, and after a successful vote at the SC level, we can officially begin the balloting process!

The first pre-MEC draft of IEEE P11073-10101b is available at https://ieee-sa.imeetcentral.com/11073pocd/home.  Password access is required (but I will be able to display content during our RTM meetings).  Follow the 11073 PoCD Working Group / STANDARDS DEV / NOMENCLATURE SG / 10101b workspace path to download a copy of <11073-10101b-D01r01.2022-09-06T09.pdf>.

Stefan Schlichting, IEEE 11073 PoCD Working Group chair, will initiate the online PoCD WG ballot tomorrow.  During the next two RTM tcons (this Wednesday, September 7, and next) I will provide a brief overview and answer any questions that you have.  We will also devote part of the IEEE 11073 PoCD and GC meeting on September 19 or 20 in Baltimore and successfully conclude WG and SC “proceed with balloting” votes at that time.

I would like to thank all of you in the IHE DEV, IHE DEV PCD and RTM community for contributions over these many years!

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

PS.  As many of you know, HIMSS will be moving away from Zoom as their teleconference service and will instead be utilizing Microsoft Teams starting this week.  Sarah Bell should have sent you a calendar entry for the updated teleconference information, but I have included a copy below.

PPS.  The total length of the draft IEEE P11073-10101b amendment is 286 pages!

________________________________________________________________________________

From the Introduction to IEEE P11073-10101b

This nomenclature amendment includes significant extensions to support:

• haemodynamic monitoring, pulse oximetry and regional cerebral oxygen monitoring
• respiratory, ventilation and anesthesia:  high-frequency ventilation, high-flow therapy, neurally adjusted ventilatory assist (NAVA) and ventilation mode based on ISO 19223
• infusion pumps, target-controlled infusion (TCI), patient-controlled analgesia (PCA) and other capabilities based on the work of the IHE DEV PCD domain program
• hemodialysis for chronic and acute care, including fluid chemistry and other fluid related metrics
• neuromuscular transmission monitoring (NMT) and stimulation modes
• signal quality index (SQI) and mapping to a unified vendor- and device-independent representation
• major extension of medical device event and alert nomenclature and grouping with existing terms
• alarm inactivation and additional attributes related to alert management and communication
• new units of measurement
• new medical device types and monitoring parameters

This amendment also includes:

• units-of-measure associated with individual numeric observations and attributes
• enumerated values with descriptions associated with individual observations and attributes

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3aMUoPzcH-LAW4XU1LFu7GKRVDdPkfC3bj5MKF72rnC701%40thread.tacv2/1660689159908?context=%7b%22Tid%22%3a%2202a9376b-a4f9-4a63-a240-52c43ebf9a89%22%2c%22Oid%22%3a%226459fea4-110a-4d17-85f0-00587211a0c0%22%7d>

Meeting ID: 239 443 642 062

Passcode: uXBce7

Download Teams<https://www.microsoft.com/en-us/microsoft-teams/download-app> | Join on the web<https://www.microsoft.com/microsoft-teams/join-a-meeting>

Or call in (audio only)

+1 872-395-5658,,390553687#<tel:+18723955658,,390553687#>   United States, Chicago

Phone Conference ID: 390 553 687#

Find a local number<https://dialin.teams.microsoft.com/bba27b0c-9f7a-4542-88cc-98cb1a3e3f75?id=390553687> | Reset PIN<https://dialin.teams.microsoft.com/usp/pstnconferencing>

Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=6459fea4-110a-4d17-85f0-00587211a0c0&tenantId=02a9376b-a4f9-4a63-a240-52c43ebf9a89&threadId=19_MUoPzcH-LAW4XU1LFu7G...@thread.tacv2&messageId=1660689159908&language=en-US>

________________________________________________________________________________

[Paul Schluter]

Greetings!

Today’s RTM tcon will be similar to last week’s, where we focused on the pre-MEC draft of the IEEE P11073-10101b nomenclature amendment.  It is also likely that some of you may have additional questions, given the additional time for review.

One of the immediate goals for the IEEE 11073 PoCD WG is to complete the online “vote to proceed with balloting” by September 17th.  After a successful PoCD WG vote, the IEEE 11073 Steering Committee will conduct a similar vote, and after a successful vote at the SC level, we can officially begin the balloting process!

I would like to thank Jan-Alrik Philipsen, Michael Faughn, John Garguilo, John Rhoads, Eldon Metz, Steven Nichols, Norman Jones, Kurt Elliason and Daniel Lee for joining our call last week.

Again, I would like to thank all of you in the IHE DEV, IHE DEV PCD and RTM and IEEE 11073 community for your contributions over the past many years to this effort!

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

PS.  As many of you know, HIMSS will be moving away from Zoom as their teleconference service and will instead be utilizing Microsoft Teams starting this week.  Sarah Bell should have sent you a calendar entry for the updated teleconference information, but I have included a copy below.  The latest Microsoft Teams invitation is attached below.

PPS.  There will be no RTM call next Wednesday, September 21, due to the IEEE 11073 and HL7 DEV SIG meetings next week in Baltimore.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, September 21, is cancelled due to the IEEE 11073 and HL7 DEV SIG meetings this week in Baltimore.

Also of note, I am very happy to say that IEEE P11073-10101b draft has unanimously passed the IEEE 11073 PoCD Working Group (WG) vote to advance to the next step, a vote by the IEEE 11073 Standards Committee (SC) to begin to the formal IEEE-SA balloting process!  The SC vote will conclude on September 30, if not sooner.

We’re getting there, and thanks again for all your help and contributions to this effort!

Thanks and best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, September 28, is cancelled.

The IEEE 11073 Standards Committee (SC) vote to begin the formal IEEE-SA balloting process for IEEE P11073-10101b does not close until September 30th, so please vote if you have not done so already.

We’re getting there, and thanks again for all your help and contributions to this effort!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

PS.  I have attached a useful summary of the devices, parameters and other IEEE P11073-10101b content below, as <P11073_10101b.TopicSummary.1e.2022-09-22T13.pdf>, discussed at the iEEE 11073 PoCD and HL7 DEV SIG meetings last week in Baltimore.

[Paul Schluter]

Greetings!

Please join our RTM tcon tomorrow, Wednesday, October 5th, at 11:00 AM CDT, using the Microsoft Teams Meeting information shown at the end of this email.

I am very happy to say that the IEEE 11073 Standards Committee (SC) has voted to approve advancing of IEEE P11073-10101b nomenclature amendment to ballot.  We can now officially begin the IEEE-SA balloting process!

I would like to thank everyone who participated in both the WG and SC votes.

The next steps will be to send the updated draft to the IEEE-SA editorial staff for Mandatory Editorial Coordination (MEC) and, simultaneously, also form the IEEE P11073-10101b ballot group.  I hope that many of you will be able to participate in the balloting of this nomenclature amendment/standard.

Before I send the draft to the IEEE-SA, there were two topics that I would like to bring up, based on our discussions during the IEEE 11073 PoCD and HL7 DEV SIG meetings in Baltimore two weeks ago.  Both of these are based on discussions we had during the meeting as well as follow-up with others in the HL7 and IEEE 11073 communities.

1.  Enumerated values for [MDC_ATTR_PT_BODY_POSN]

During the Baltimore meeting, Elliot Silver (ResMed) mentioned that we were missing several patient positions, such as right- and left-lateral (recumbent), and that they should be added to our list of enumerated values for [MDC_ATTR_PT_BODY_POSN].  I have also added more precise Fowlers terms that can be used in lieu of “sitting" and “supine”.   For the four Fowlers positions, I have also added specific angles for both beds and wheelchairs, since they are reported differently.

I believe the list below is sufficient for the majority of acute and home care settings, but we should consider additional patient positioning terms (with references that define them along with their clinical utility) if we are missing any.  [The original list had seven terms, based on the earlier IHE PCD SpO2 supplement, and were appropriate for reporting patient position for SpO2, NIBP and many other measurements in most acute care settings.]  For example, should we consider adding common surgical positioning terms like “Lithotomy Position”, “Jackknife Position”, “Kidney Position”, “Sim’s Position” and possibly others?  [This barely scratches the surface of the positioning capabilities of modern-day surgical tables, and it may be better to leave MDC_ATTR_PT_BODY_POSN to common acute and home-health care positions for now.]

Table A.3.2.1.2.1.1—Enumerated values for [MDC_ATTR_PT_BODY_POSN]

Enum_Values	Enum_Descriptions	Comments
sitting	Sitting (also known as Fowler’s position)
standing	Standing
supine	Supine, lying face upward.
prone	Prone, lying face downward.
reverseTrendelenburg	The reverse Trendelenburg position is surgical position in which the lower extremities are leveled lower than the head and neck. It is the opposite of the Trendelenburg position, in which the head and the neck are below the lower extremities.
TrendelenburgPosition	In the Trendelenburg position the body is laid flat on the back (supine position) with the feet higher than the head by 15 to 30 degrees. This is a standard position used in abdominal and gynecological surgery. It allows better access to the pelvic organs as gravity pulls the intestines away from the pelvis. It was named after the German surgeon Friedrich Trendelenburg.
lowFowlersPosition	The Low-Fowler's position is when a patient is lying in bed in a supine position with the head of the bed is raised at approximately 15 to 30 degrees.  [This is equivalent to 150 to 175 degrees of open seat to back angle in a wheelchair.]
semiFowlersPosition	The Semi-Fowler's position is when a patient is lying in bed in a supine position with the head of the bed at approximately 30 to 45 degrees. Patients who are on tube feedings are typically placed in the Semi-Fowler's position. Were the patient to lay flat the tube feeding fluid can possibly run into the lungs. Elevating the head of the bed to 30 degrees decreases the risk of the patient aspirating the tube feeding fluid.  [This is equivalent to 135 to 150 degrees of open seat to back angle in a wheelchair.]
standardFowlers	The Standard-Fowler's position is when a patient is sitting in bed with the head of the bed at approximately 45 to 60 degrees.  [This corresponds to 120 to 145 degrees of open seat to back angle in a wheelchair.]
highFowlers	The High-Fowler's position is when a patient is sitting in bed with the head of the bed at approximately 90 degrees.  [This corresponds to 90 degrees of open seat to back angle in a wheelchair.]
rightLateralRecumbent	The Right Lateral Recumbent (RLR) is when the patient is lying on their right side.
lefttLateralRecumbent	The Left Lateral Recumbent, or LLR, is when the patient is lying on their left side.

2.  Assigning globally unique numeric codes for enumerated values

Several people recommended that we assign globally unique numeric codes for enumerated values.  This would be more aligned with other vocabulary standards such as LOINC, where LOINC “answer” strings and groups are now assigned unique alpha-numeric identifier codes.

Here’s an example of how this will be specified in IEEE P11073-10101b:

For the HL7 V2 message examples shown below, the following enumerated values for MDC_NCC_WIRELESS_AUTH are used.  The Part::Code and CF_CODE10 values are example values.

Table A.3.2.13.2.3—Enumerated values for [MDC_NCC_WIRELESS_AUTH]

Enum_Values	Enum_Descriptions	Part::Code	CF_CODE10
OPEN	No security	7::18471	477223
WEP	Wired Equivalent Privacy	7::18472	477224
WPA-PSK	Wi-Fi Protected Access (WPA) - Pre-shared key exchange	7::18473	477225
WPA-ENT	Wi-Fi Protected Access (WPA) – Enterprise authentication	7::18474	477226
WPA2-PSK	Wi-Fi Protected Access II (WPA2) - Pre-shared key exchange	7::18475	477227
WPA2-ENT	Wi-Fi Protected Access II (WPA2) – Enterprise authentication	7::18476	477228
WPA3-PSK	Wi-Fi Protected Access® (WPA3) – Personal mode, Simultaneous Authentication of Equals (WPA3-SAE)	7::18477	477229
WPA3-ENT	Wi-Fi Protected Access® 3 (WPA3) – Enterprise authentication	7::18478	477230

This will support both the traditional encoding of sending the Enum_Value token as a constrained string HL7 v2 ‘ST’ datatype:

    OBX|3|ST|69418^MDC_NCC_WIRELESS_AUTH^MDC|1.0.1.5|WPA2-ENT||||||F

Or as a fully populated HL7 V2 ‘CWE’ datatype with a globally unique context-free numeric code defined in Partition 7:

    OBX|3|CWE|69418^MDC_NCC_WIRELESS_AUTH^MDC|1.0.1.5|477228^WPA2-ENT^MDC||||||F 

Although it would be possible to automatically generate a unique REFID for each { _ENUM_GROUP :: Enum_Value } pair, it is not clear that sending it the message would provide much validation benefit nor clarity compared to sending the shorter Enum_Value string as we currently do today.

That’s it for now, and I look forward to discussing these and possibly other topics tomorrow.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<P11073_10101b.TopicSummary.1e.2022-09-22T13.pdf>

[Paul Schluter]

Greetings!

Please join our RTM tcon this Wednesday, October 12th, at 11:00 AM CDT, using the Microsoft Teams Meeting information below.

We will have a follow-up discussion regarding the list of body positions that we discussed last week.  Please review the extended list of 21 items immediately below.  The list now supports additional commonly used body positions typically used in acute care, the operating room, step-down units, clinics and home care.  It is not intended to cover all of radiology and patient positions that are possible using more sophisticated surgical tables.

The list now includes “unknown” and “upright”, the latter to support devices with a built-in accelerometer attached to the patient's chest (but not an additional accelerometer attached to the lower extremities to distinguish between sitting, standing or bending over).  The Fowler’s position is now split into four widely used subcategories (low, semi, standard and high) since these could be easily measured by devices, including wheelchairs.  Additional commonly-used positions have also been added.

Although numerous references were reviewed during this work, two were particularly useful for determining a reasonably useful set that could be expanded in the future.  The first, https://nurseslabs.com/patient-positioning/, provided diagrams, definitions and rationale for patient positions used in all care areas.  The second, https://dicom.nema.org/medical/dicom/current/output/html/part16.html#sect_CID_20, lists patient positions specified by DICOM Table CID 20. Patient Orientation Modifier.  [The list below includes all positions from the first reference and all from the DICOM CID 20 list except for “anatomical”, “kneeling”, “frog”, "stooped-over”, "curled-up”, and “lordotic”.  If you believe any of these should be included now, please advise me prior to or during this week’s RTM call.]  [Incidentally, two on-line medical dictionaries (https://medical-dictionary.thefreedictionary.com/position and  https://www.tabers.com/tabersonline/view/Tabers-Dictionary/738876/all/position) provide similar lists containing over 60+ positions each.]

The current table now includes 21 patient positions.  We will reserve 11 additional contiguous code slots, for a total of 32 contiguous code slots, for future expansion.  It will also be possible to expand beyond the original 32 contiguous code slots if we need to.

I would like to thank Michael Faughn, Eldon Metz, Kurt Elliason, Daniel Lee, Marufur Rahman, Elliot Silver, Javier Espina Perez and Jan-Alrik Philipsen for attending and contributing to last week’s RTM tcon.

That’s it for now, and I look forward to discussing these and possibly other topics this Wednesday!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

Enum_Values	Enum_Descriptions
unknown	The patient position is unknown or cannot be determined based on the information available to the device (sensor, manual entry or by other means).
upright	The patient's torso is in an upright or nearly vertical orientation, regardless of the position of the lower extremeties (e.g. sitting or standing).

sitting	Sitting (also known as Fowler’s position)
standing	Standing
supine	Supine, lying face upward.
prone	Prone, lying face downward.

reverseTrendelenburg	In the reverse Trendelenburg position, the patient is lying flat on the back (supine position) with the head and neck elevated with respect to the lower extremeties.  It is the opposite of the Trendelenburg position, in which the head and the neck are below the lower extremities.
Trendelenburg	In the Trendelenburg position, the patient is lying flat on the back (supine position) with the feet higher than the head by 15 to 30 degrees. This is a standard position used in abdominal and gynecological surgery. It allows better access to the pelvic organs as gravity pulls the intestines away from the pelvis. It was named after the German surgeon Friedrich Trendelenburg.
lowFowlers	In the low Fowler's position, the patient is lying in bed in a supine position with the head of the bed is raised at approximately 15 to 30 degrees.  [This is equivalent to 150 to 175 degrees of open seat to back angle in a wheelchair.]
semiFowlers	In the semi-Fowler's position, the patient is lying in bed in a supine position with the head of the bed at approximately 30 to 45 degrees. Patients who are on tube feedings are typically placed in the Semi-Fowler's position. Were the patient to lay flat the tube feeding fluid can possibly run into the lungs. Elevating the head of the bed to 30 degrees decreases the risk of the patient aspirating the tube feeding fluid.  [This is equivalent to 135 to 150 degrees of open seat to back angle in a wheelchair.]
standardFowlers	In the standard Fowler's position, the patient is sitting in bed with the head of the bed at approximately 45 to 60 degrees.  [This corresponds to 120 to 145 degrees of open seat to back angle in a wheelchair.]
highFowlers	In the high Fowler's position, the patient is sitting in bed with the head of the bed at approximately 90 degrees.  [This corresponds to 90 degrees of open seat to back angle in a wheelchair.]
orthopneicPosition	In the orthopneic or tripod position, the patient is in a sitting position or on the side of the bed with an overbed table in front to lean on and several pillows on the table to rest on.
lateralRecumbent	In the lateral recumbent (decubitus) position, the patient lies on one side of their body with the top leg in front of the bottom leg and the hip and knee flexed. Flexing the top hip and knee and placing this leg in front of the body creates a wider, triangular base of support and achieves greater stability.
rightLateralRecumbent	In the right lateral recumbent (decubitus) position, the patient is lying on their right side.
lefttLateralRecumbent	In the left lateral recumbent (decubitus) position, the patient is lying on their left side.
SimsPosition	In the Sim's (semi-prone) position, the patient assumes a posture halfway between the lateral and the prone positions. The lower arm is positioned behind the client, and the upper arm is flexed at the shoulder and the elbow. The upper leg is more acutely flexed at both the hip and the knee, than is the lower one.
lithotomyPosition	in the lithotomy position, the patient is on their back with hips and knees flexed and thighs apart.
knee-chestPosition	The knee-chest position can be in lateral or prone position. In lateral the patient lies on their side, torso lies diagonally across the table, hips and knees are flexed. In prone, the patient kneels on the table and lower shoulders on to the table so chest and face rests on the table.
jackknifePosition	In the jackknife position (also known as Kraske position), the patient's abdomen lies flat on the bed. The bed is scissored so the hip is lifted and the legs and head are low.
kidneyPosition	In the kidney position, the patient assumes a modified lateral position wherein the abdomen is placed over a lift in the operating table that bends the body. Patient is turned on their contralateral side with their back placed on the edge of the table.

[Paul Schluter]

Greetings!

The RTM tcon for this Wednesday, October 19th, is cancelled due to the IHE DEV F2F meeting at Cape Canaveral this week.

Also of note, I am very happy to say that the IEEE P11073-10101b Ballot Group has now been formed and ballot pool is considered ‘balanced’.

After Michael Faughn has had a chance to review the final list of terms and code assignments “one last time” and incorporate them into RTMMS, the next step is to send the draft of IEEE P11073-10101b to the IEEE-SA editorial staff to begin the Mandatory Editorial Coordination (MEC) process, and after that has been completed, the first ballot review cycle can begin.

I would also like to thank everyone who joined the RTM call last week, including Monroe Pattillo, Eldon Metz, Steven Nichols, Jan-Alrik Philipsen and John Garguilo.  We reviewed recent additions to the list of enumerated patient position names (the list is now reasonably complete, but we can always update it during balloting).

Thanks again for all your help and best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for this Wednesday, October 26th, is cancelled.  I do not have any new topics to discuss.

IEEE P11073-10101b is nearly ready to be released for balloting, pending satisfactory of a few items that were found during Mandatory Editorial Coordination (MEC) review, such as obtaining copyright permission letters for several items.  Michael Faughn is also reviewing the final list of new terms and code assignments prior to incorporating them in RTMMS.

A few other items will need to be resolved before the final recirculation ballot, and I do not anticipate any difficulties with those.

Thanks again for all your help and best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for this Wednesday, November 2nd, is cancelled.  I do not have any new topics to discuss.

The first ballot draft of IEEE P11073-10101b-D1 is now in the capable hands of the IEEE-SA and practically all requirements for releasing the draft for balloting have been met.  

Thanks again for all your help and best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for this Wednesday, November 9th, is cancelled.  I do not have any new topics to discuss.

We’re still waiting for the IEEE-SA legal team to sign off on the copyright permission letter we sent last week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcons for today, November 16th, and next Wednesday, November 23rd, are cancelled.  I do not have any new topics to discuss.

We’re still waiting for the IEEE-SA legal team to sign off on the copyright permission letter we sent two weeks ago.

For those of you in the United States (and elsewhere), have a very enjoyable Thanksgiving Holiday!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, November 30th, is cancelled.  I do not have any new topics to discuss.

I am happy to say that we now have an acceptable copyright permission letter for the introductory dialysis material, so we should be able to start balloting in a day or so.

[Paul Schluter]

Greetings!

As those of you that are on the ballot group are likely aware, balloting was opened this morning for IEEE P11073-10101b-D1.

The ballot closes at 23:59 UTC-12 on December 31, 2022.

If you have any questions, please do not hesitate to contact me, Stefan Schlichting <stefan.sc...@ornet.org> or Tom Thompson" < thomas....@ieee.org>.  For those of you who have not joined the IEEE-SA balloting group for IEEE P11073-10101b but would like to obtain a copy of the document as a potential “Public Reviewer”, please contact Tom Thompson or the IEEE-SA regarding that option.

Thank you all for your thoughtful contributions and discussions over these many years, and have an enjoyable Holiday Season!

[Paul Schluter]

Greetings!

The RTM tcon for this Wednesday, December 7th, is cancelled.  I do not have any new topics to discuss.

Balloting was opened for IEEE P11073-10101 on December 2nd and will close on December 31st.  Please feel free to contact me or Stefan Schlichting <stefan.sc...@ornet.org> if you have any questions.

Thanks again for all your help and best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Dec 2, 2022, at 10:51 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

As those of you that are on the ballot group are likely aware, balloting was opened this morning for IEEE P11073-10101b-D1.

The ballot closes at 23:59 UTC-12 on December 31, 2022.

If you have any questions, please do not hesitate to contact me, Stefan Schlichting <stefan.sc...@ornet.org> or Tom Thompson" < thomas....@ieee.org>.  For those of you who have not joined the IEEE-SA balloting group for IEEE P11073-10101b but would like to obtain a copy of the document as a potential “Public Reviewer”, please contact Tom Thompson or the IEEE-SA regarding that option.

Thank you all for your thoughtful contributions and discussions over these many years, and have an enjoyable Holiday Season!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcons for Wednesday, December 14th, 21st and 28th are cancelled.  I do not have any new topics to discuss.

Balloting was opened for IEEE P11073-10101-D1 on December 2nd and will close on December 31st.  Please feel free to contact me or Stefan Schlichting <stefan.sc...@ornet.org> if you have any questions.

Thanks again for all your contributions to standardized interoperability and nomenclatures this year and have a wonderful Holiday Season!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Dec 7, 2022, at 8:43 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

The RTM tcon for this Wednesday, December 7th, is cancelled.  I do not have any new topics to discuss.

Balloting was opened for IEEE P11073-10101 on December 2nd and will close on December 31st.  Please feel free to contact me or Stefan Schlichting <stefan.sc...@ornet.org> if you have any questions.

Thanks again for all your help and best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Dec 2, 2022, at 10:51 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

As those of you that are on the ballot group are likely aware, balloting was opened this morning for IEEE P11073-10101b-D1.

The ballot closes at 23:59 UTC-12 on December 31, 2022.

If you have any questions, please do not hesitate to contact me, Stefan Schlichting <stefan.sc...@ornet.org> or Tom Thompson" < thomas....@ieee.org>.  For those of you who have not joined the IEEE-SA balloting group for IEEE P11073-10101b but would like to obtain a copy of the document as a potential “Public Reviewer”, please contact Tom Thompson or the IEEE-SA regarding that option.

Thank you all for your thoughtful contributions and discussions over these many years, and have an enjoyable Holiday Season!

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Happy New Years!  i trust that you all had an enjoyable Holiday Season!

The RTM tcon for today, Wednesday, January 4th, is cancelled.  I currently do not have any new topics to discuss.

The ballot for IEEE P11073-10101b Health informatics -- Device Interoperability -- Part 10101: Foundational -- Nomenclature -- Amendment 2: Additional definitions has been extended because a sufficient return rate was not achieved by the previously stated ballot close date of December 31, 2022. The ballot is now projected to close on February 1st, 2023. 

If you have not already done so, it is very important that you enter a vote and comments. Your prompt response would be greatly appreciated.

Should a sufficient return rate be achieved prior to February 1st, the ballot will automatically close on the day that the sufficient return rate is achieved.  This is very important in our case (10101b) since I will be out of the country starting on February 2nd for several weeks.  It would be highly desirable to begin reviewing and reconciling ballot comments by Wednesday, January 18, so that a recirculation ballot could be started before February 1st.

Thanks again for all your help and best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcons for Wednesday, January 11th and January 18, are cancelled.

The ballot for IEEE P11073-10101b-D1 Health Informatics -- Device Interoperability -- Part 10101: Foundational -- Nomenclature -- Amendment 2: Additional definitions is still underway since a sufficient return rate has not been achieved. The ballot is now projected to close on February 1st, 2023.  If you have not already done so, it is very important that you enter a vote and comments.  Your prompt response would be greatly appreciated. 

Since the 10101b-D1 ballot has not closed, we may only be able to discuss a subset of the ballot comments received on Tuesday, January 17 from 9:40 to 10:30 AM PST, 11:40 AM to 12:30 PM CST and 12:40 to 1:30 PM EST during the IEEE 1073 PoCD WG meeting/tcon.  The agenda and teleconference information for the IEEE 11073 PoCD and HL7 DEV meetings is available at https://confluence.hl7.org/pages/viewpage.action?pageId=144990669 .

Since the HL7 DEV meeting overlaps with the RTM tcon for next week, the RTM tcon for January 18th is also cancelled.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please join our RTM tcon for today, Wednesday, January 25th at 11:00 AM CST.

I am very happy to announce that the IEEE P11073-10101b-D1 ballot draft passed with an approval rate of 89% and 24 comments.  Several members of the balloting group are reviewing and reconciling the comments and that process is going relatively smoothly (although we did manage to generate one email thread that was over 30 pages long).  I am hoping that we will be able to turn around the next draft, IEEE P11073-10101b-D2, by the end of this month for a recirculation ballot that will continue through most of February.

I have attached a copy of the 10101b nomenclature presentation I gave on January 17th, with a focus on defining Reference IDs for the 250+ enumerated values that were defined in 10101b.

I am happy to say that we found a simple solution to this problem after them IEEE 11073 PoCD meeting concluded last week.  In cases where the originally proposed REFID included hyphens ‘-‘ and possibly other characters that do not comply with [A-Za-z_][A-Za-z0-9_]* required for C or C++ identifiers, we will also create a “preferred” REFID-synonym by mapping the special characters (currently ‘-‘ and ‘.’ only) to an underscore ‘_’.

Stated more clearly, the [A-Za-z_][A-Za-z0-9_]* C and C++ compatible identifiers would be the “preferred” REFID and the original REFID with hyphens is the “less preferred”.  There aren’t that many of these in 10101b enumeration group and value pairs, and we already have the mechanism to support REFID-synonyms this in the IEEE 11073 printed/published standard, RTMMS and message modeling and test tools since we’ve had REFID-synonyms for quite some time.

This solution is similar to the existing 10103 IDC vendor-specific enumerated values that include hyphens and that have been incorporated in shipping products for the past ten years.

Members and non-members of the IEEE P11073-10101b ballot group are welcome to join this call, but I may need to guide the discussion from time-to-time to comply with the IEEE-SA guidelines regarding what can be discussed (or not).

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<P11073-10101b-D1.NomenclatureStatus.3c.2023-01-17T10.presented.pdf>>

[Paul Schluter]

Greetings!

First, the RTM tcons for today, Wednesday, February 1st and the next three Wednesdays, February 8, 15 and 22nd, are cancelled.  

My wife Kathy and I are looking forward to our trip to Egypt and Jordan over the next several weeks.  We plan to return on February 22nd and it is likely that the next RTM tcon will be held on Wednesday, March 1st.

Second, I am very happy to say that IEEE P11073-10101b-D2 has been submitted to the IEEE-SA and we expect the recirculation ballot to begin very shortly.

I would like to thank everyone who submitted ballot comments and participated in our ballot reconciliation discussions last week.  We were able to come to a resolution on practically all of the comments and believe that the updated draft is ready for recirculation.  If you have any questions about the ballot, please contact Tom Thompson at thomas....@ieee.org or Stefan Schlichting at stefan.sc...@ornet.org .

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

 

Join on your computer, mobile app or room device   (updated on 2023-01-24T13)

Click here to join the meeting

Meeting ID: 290 357 564 578 
Passcode: jjp3vA

Download Teams | Join on the web

[Paul Schluter]

Greetings!

First, the RTM tcons for today, Wednesday, March 1st and next Wednesday, March 8th, are cancelled, since IEEE P11073-10101b-D2 is out for recirculation ballot until 23:59 UTC-12 on 08 Mar 2023.

It is likely that the next RTM tcon will be held on Wednesday, March 15th, since by then we will have had time to review new comments and propose preliminary resolutions.

I would like to thank everyone who have taken the time to review IEEE P11073-10101b-D2.  If you have any questions about the ballot, please feel free to contact me, Tom Thompson at thomas....@ieee.org or Stefan Schlichting at stefan.sc...@ornet.org .

And finally, Kathy and I had an absolutely wonderful time in Egypt and Jordan, and we’re now fully refreshed and looking forward to reengaging with all our activities, friends and colleagues back home.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, March 15th, is cancelled.

I am currently reviewing the IEEE P11073-10101b-D2 comments and working with several individuals and groups to resolve most of them.

I would like to thank everyone, especially those in the SDC community, for taking the time to review IEEE P11073-10101b-D2.

I would like to acknowledge that effective this month, Michael Kipness will be the Program Manager for the EMB 11073 Standards Committee (11073 SC) and its Working Groups (WGs).  Michael will be replacing Tom Thompson who has worked so ably with many of us for the past many years.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Mar 1, 2023, at 8:35 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

First, the RTM tcons for today, Wednesday, March 1st and next Wednesday, March 8th, are cancelled, since IEEE P11073-10101b-D2 is out for recirculation ballot until 23:59 UTC-12 on 08 Mar 2023.

It is likely that the next RTM tcon will be held on Wednesday, March 15th, since by then we will have had time to review new comments and propose preliminary resolutions.

I would like to thank everyone who have taken the time to review IEEE P11073-10101b-D2.  If you have any questions about the ballot, please feel free to contact me, Tom Thompson at thomas....@ieee.org or Stefan Schlichting at stefan.sc...@ornet.org .

And finally, Kathy and I had an absolutely wonderful time in Egypt and Jordan, and we’re now fully refreshed and looking forward to reengaging with all our activities, friends and colleagues back home.

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

On Feb 1, 2023, at 8:17 AM, Paul Schluter <pssch...@gmail.com> wrote:

Greetings!

First, the RTM tcons for today, Wednesday, February 1st and the next three Wednesdays, February 8, 15 and 22nd, are cancelled.  

My wife Kathy and I are looking forward to our trip to Egypt and Jordan over the next several weeks.  We plan to return on February 22nd and it is likely that the next RTM tcon will be held on Wednesday, March 1st.

Second, I am very happy to say that IEEE P11073-10101b-D2 has been submitted to the IEEE-SA and we expect the recirculation ballot to begin very shortly.

I would like to thank everyone who submitted ballot comments and participated in our ballot reconciliation discussions last week.  We were able to come to a resolution on practically all of the comments and believe that the updated draft is ready for recirculation.  If you have any questions about the ballot, please contact Tom Thompson at thomas....@ieee.org or Stefan Schlichting at stefan.sc...@ornet.org .

Thanks and regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

Join on your computer, mobile app or room device   (RTM meeting time:  Wednesdays at 11:00 AM Central US)

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, March 22nd, is cancelled.

I am currently reviewing the IEEE P11073-10101b-D2 comments and working with several individuals and groups to resolve many of them.

There were over thirty comments related to infusion pumps and I would prefer that they be jointly reviewed by the IHE DEV Pump Working Group and members of the SDC community.  Due to vacations and other scheduling constraints, we will not be able to begin this effort until next week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcons for today, Wednesday, March 29th, and next Wednesday, April 5th, are cancelled.

The IEEE P11073-10101b-D2 pump related comments are currently being reviewed by two members of the IHE PCD infusion pump leadership team and I am working with other individuals regarding other comments.

Our goal is to resolve as many of the comments as we can in a manner that satisfies everyone, but it is also likely that a dozen or so comments will require deeper discussion.

Best regards,

Paul Schluter

email:  pssch...@gmail.com
cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, April 12th, is cancelled.

We will be using this time slot to discuss and resolve IEEE P11073-10101b-D2 comments, on a separate call.

I am happy to say that we are making reasonable progress, with the majority of comments largely resolved and about half memorialized in the next draft, IEEE P11073-10101b-D3.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcon for Wednesday, April 19th, is cancelled.  HIMSS23 is being held in Chicago this week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings,

The RTM tcon for today, Wednesday, April 26th, is cancelled.

We will be using this time slot to discuss and resolve IEEE P11073-10101b-D2 comments, on a separate call.

I am happy to say that we are just about done with ballot comment review and expect to have the next draft, IEEE P11073-10101b-D3, available for a recirculation ballot by the end of next week.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcons for today, Wednesday, May 3rd, and next Wednesday, May 10th, are cancelled.

I am very happy to say that the IEEE P11073-10101b-D3 recirculation ballot has been started.  Many thanks are in order to everyone who helped out with this effort, especially members of the IHE PCD Infusion Pump Working Group who were also affiliated with the IEEE P11073-10101b ballot group.  I would also like to thank Stefan Schlichting, PoCD WG Chair, and Michael Kipness and Lisa Perry of the IEEE-SA, for their help and guidance in this effort.

For those of you who are IEEE-SA members, the final review versions of IEEE P11073-10101b-D3 dated 2023-05-01T11 are now posted on the iMeetCentral folder:

11073 PoCD Working Group / STANDARDS DEV / NOMENCLATURE SG / 10101b

https://ieee-sa.imeetcentral.com/11073pocd/folder/WzIwLDE1NjEzNjAyXQ/

as files

<<P11073-10101b-D3.2023-05-01T11.clean.pdf>>

<<P11073-10101b-D3.2023-05-01T11.redline.pdf>>

Since the IEEE P11073-10101b-D3 recirculation ballot materials have not been sent to the balloting group at this time, we will wait until the IEEE 11073 PoCD WG F2F (and virtual) meeting next Monday, May 8th, followed by the HL7 DEV SIG meetings on Tuesday through Thursday (and possibly Friday), for in-depth discussion of some of the comments and proposed dispositions.

Monday, May 8th, 2023  11:00 AM to 5 PM US CST 

Please refer to the attached <2023-05 POCD 11073--IEEE SA_draft Agenda-members v1.doc> agenda, drafted by Konstantinos “Kosta” Makrodimitris, PhD, of the FDA.

I will give a short presentation of IEEE P11073-10101b as part of the RTM update, starting at 13:45 PM US CST, followed by more in-depth discussion of selected comments and proposed dispositions.

Tuesday, May 9th - Thursday, May 11th  9:00 AM to 5 PM US CST, using HL7 “Quarters”  (there could be a meeting on Friday, too)

The draft agenda for the DEV SIG meetings is available at:  https://confluence.hl7.org/pages/viewpage.action?pageId=161061969

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

<<2023-05 POCD 11073--IEEE SA_draft Agenda-members v1.doc>>

[Paul Schluter]

Greetings!

Please join our RTM tcon for today, Wednesday, May 17th, at 11:00 AM CDT.

The 10-day recirculation ballot of IEEE P11073-10101b-D3 started last week and is scheduled to close on Saturday, May 20th.  This will provide a few days to review the ballot comments prior to the upcoming IHE PCD F2F next week in Alexandria, VA, and to solicit feedback from the attendees there.

For today’s RTM call I will summarize the major changes since the 10101b-D2 draft and address any questions that you may have.

The Teams meeting access information is provided below.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

PS.  Next Wednesday’s RTM tcon on May 24th is cancelled due to the upcoming IHE PCD F2F meeting next week.

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, May 31st, is cancelled.

Regarding IEEE P11073-10101b-D3, the balloting results are in, and we are now down to four comments plus a numeric code assignment correction.

We will likely have an RTM tcon next Wednesday, June 7th, to review the proposed dispositions with members of the balloting group.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

Please feel free to join our RTM tcon for today, Wednesday, June 7, at 11:00 AM CDT.

We plan to discuss a recent proposal to split _UOM_DOSE_QUAN into _UOM_DOSE_QUAN “drug amount (mass)” and _UOM_DOSE_QUAN_LIQUID “drug amount (volume)”.  The change will be applied to the 14 “drug amount” quantities defined in IEEE P11073-10101b that will now list two unit of measure groups:

     _UOM_DOSE_QUAN

     _UOM_DOSE_QUAN_LIQUID

The change will not affect message content but will help us monitor and maintain the "thread of calculation" when processing or validating a sequence of messages, starting with the RXG-15 and RXG-16 in the initial PCD-03 message.  It is also aligned with a similar change made to “dose rate” that is comprised of two unit of measure groups, _UOM_DOSE_RATE and _UOM_DOSE_RATE_LIQUID.

Everyone who has reviewed the proposal agrees with the change.  We will use the call today to see if others have any questions or concerns.

Otherwise, we are largely on target to release the next draft of IEEE P11073-10101b-D4 for a 10-day ballot review starting on or around June 15th.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 14th, is cancelled.  I currently do not have any new topics to discuss for today.

IEEE P11073-10101b-D4 has been submitted to the IEEE-SA for a 10-day recirculation ballot.  I am very happy to say that we were able to favorably address all of the remaining comments and I am keeping my fingers crossed this will be the last recirculation ballot.

The pdfs will also be posted on the IEEE-SA site for access by members of the IEEE 11073 PoCD Working Group.

I would also like to thank everyone in the Pump WG who helped resolve the last set of comments over the past several weeks.

Best regards,

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026

[Faughn, Michael R. (Fed)]

Due to a planned NIST Systems Outage for maintenance, RTMMS will be unavailable for use this weekend (starting June 16^th and ending June 20^th).

 

Michael Faughn

[Paul Schluter]

Greetings!

The RTM tcon for today, Wednesday, June 21st, is cancelled.  I currently do not have any new topics to discuss today.

IEEE P11073-10101b-D4 has been submitted to the IEEE-SA for a 10-day recirculation ballot, likely starting this evening.  I am very happy to say that we were able to favorably address all of the remaining comments.  I am keeping my fingers crossed this will be the last recirculation ballot.

The pdfs have been posted for access by members of the IEEE 11073 PoCD Working Group on the IEEE-SA iMeetCentral folder:

11073 PoCD Working Group / STANDARDS DEV / NOMENCLATURE SG / 10101b

https://ieee-sa.imeetcentral.com/11073pocd/folder/WzIwLDE1NjEzNjAyXQ/

as files

<<P11073-10101b-D4.2023-06-12T10.clean.pdf>>

<<P11073-10101b-D4.2023-06-12T10.tracked.pdf>>

Best regards, and enjoy your summer!

Paul Schluter

email:  pssch...@gmail.com

cell:  (414) 702-2026